Question: How do I resolve the "Unable to verify/create output bucket" error in Amazon Athena?

"When I run Amazon Athena queries in SQL Workbench/J, in AWS Lambda, or with an AWS SDK, I get the error: "Unable to verify/create output bucket.""

Answer: "When I run Amazon Athena queries in SQL Workbench/J, in AWS Lambda, or with an AWS SDK, I get the error: "Unable to verify/create output bucket."Short descriptionHere are some common causes of this error:The Amazon Simple Storage Service (Amazon S3) bucket that you specified for the query result location doesn't exist.The AWS Identity and Access Management (IAM) policy for the user or role that runs the query doesn't have the required Amazon S3 permissions, such as s3:GetBucketLocation.ResolutionIf you manually set the query result location, you must confirm that the S3 bucket exists. Then, check the IAM policy for the user or role that runs the query:Confirm that the permissions in the following example policy, such as s3:GetBucketLocation are allowed.Be sure that the IAM policy does not contain a Deny statement that uses aws:SourceIp or aws:SourceVpc to restrict S3 permissions.Note: If the bucket already exists, then the s3:CreateBucket permission isn't required. If you manually set the query result location, then don't include arn:aws:s3:::aws-athena-query-results-* in the policy. The policy must include arn:aws:s3:::query-results-custom-bucket and arn:aws:s3:::query-results-custom-bucket/* only if you manually set the query result location.{    "Version": "2012-10-17",    "Statement": [        {            "Effect": "Allow",            "Action": [                "s3:GetBucketLocation",                "s3:GetObject",                "s3:ListBucket",                "s3:ListBucketMultipartUploads",                "s3:ListMultipartUploadParts",                "s3:AbortMultipartUpload",                "s3:CreateBucket",                "s3:PutObject"            ],            "Resource": [                "arn:aws:s3:::aws-athena-query-results-*",                "arn:aws:s3:::query-results-custom-bucket",                "arn:aws:s3:::query-results-custom-bucket/*"            ]        }    ]}Related informationAccess to Amazon S3Bucket policy examplesControlling access from VPC endpoints with bucket policiesExample - object operationsFollow"


Question: How can I disable the API Gateway default endpoint for REST or HTTP APIs?

I want to allow clients to invoke my APIs only using the custom domain name. How can I deactivate the default API execute-api endpoint URL for Amazon API Gateway REST or HTTP APIs?

Answer: "I want to allow clients to invoke my APIs only using the custom domain name. How can I deactivate the default API execute-api endpoint URL for Amazon API Gateway REST or HTTP APIs?Short descriptionAPI Gateway REST APIs and HTTP APIs use a default API endpoint in the following format: "https://{api_id}.execute-api.{region}.amazonaws.com". If you use a custom domain name for your API Gateway REST or HTTP APIs, you can deactivate the default endpoint. This allows all traffic to route to your APIs through the custom domain name.ResolutionFollow these steps to disable the default endpoint using the API Gateway console, AWS Command Line Interface (AWS CLI), or AWS CloudFormation.Note:If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.After you activate or deactivate the default endpoint, a deployment is required for the update to take effect.API Gateway consoleREST APIOpen the API Gateway console.In the navigation pane, choose APIs, and then choose your REST API.In the navigation pane, choose Settings.For the Default Endpoint, choose Disabled, and then choose Save Changes.In the navigation pane, choose Resources, Actions, and then choose Deploy API.HTTP APIOpen the API Gateway console.In the navigation pane, choose APIs, and then choose your HTTP API.In the navigation pane, choose Settings.For the Default Endpoint, choose Disabled, and then choose Save Changes.In the navigation pane, choose Resources, Actions, and then choose Deploy API.AWS CLIREST APIRun the AWS CLI command update-rest-api similar to the following:aws apigateway update-rest-api --rest-api-id abcdef123 --patch-operations op=replace,path=/disableExecuteApiEndpoint,value='True'To deploy the updated API, run the AWS CLI command create-deployment similar to the followingaws apigateway create-deployment --rest-api-id abcdef123 --stage-name devNote: Replace api_id abcdef123 and stage_name dev with your REST API ID and respective stage.HTTP APIRun the AWS CLI commandupdate-api similar to the following:aws apigatewayv2 update-api --api-id abcdef123 --disable-execute-api-endpointTo deploy the updated API, run the AWS CLI command create-deployment similar to the following:aws apigatewayv2 create-deployment --api-id abcdef123 --stage-name devNote: Replace api_id abcdef123 and stage_name dev with your HTTP API ID and respective stage.CloudFormation templateTo disable the default endpoint from a CloudFormation template, you can set the DisableExecuteApiEndpoint parameter to True. Update the CloudFormation template for REST API or HTTP API.Important: Disabling the default endpoint results in HTTP 403 Forbidden errors if the API is invoked using the default endpoint URL.Related informationHow do I troubleshoot HTTP 403 errors from API Gateway?Follow"


Question: How do I troubleshoot primary node failure with error “502 Bad Gateway” or “504 Gateway Time-out” in Amazon EMR?

My Amazon EMR primary node is failing with a "502 Bad Gateway" or "504 Gateway Time-out" error.

Answer:
"My Amazon EMR primary node is failing with a "502 Bad Gateway" or "504 Gateway Time-out" error.Short descriptionAn EMR primary node might fail with one of the following errors:The master failed: Error occurred:?? <title>502 Bad Gateway</title> ??
502 Bad Gateway

nginx/1.20.0?? ?? ??-or-The master failed: Error occurred: ??<title>504 Gateway Time-out</title>????
504 Gateway Time-out
??
nginx/1.16.1??????The following are common reasons for these errors:The instance-controller daemon is in the stopped state or is down on the primary node instance.The primary node runs out of memory or disk space.The Amazon Elastic Compute Cloud (Amazon EC2) instance status checks fail.ResolutionTroubleshoot primary node instance-controller daemon failuresThe primary node's instance controller (I/C) is the daemon that communicates with the EMR control plane and the rest of the cluster. If the instance controller can't communicate with the EMR control plane, then the primary node is classified as unhealthy and the cluster is terminated.To resolve this, analyze the instance-controller logs to determine why the process failed. The instance-controller logs are located at /emr/instance-controller/log/.If termination protection is turned on, SSH into the primary node and restart the instance-controller process.In Amazon EMR 5.30.0 and later release versions:1.    Use the following command to check the status of the I/C:sudo systemctl status instance-controller.service2.    Use the following command to restart the I/C if the status is down:sudo systemctl start instance-controller.serviceIn Amazon EMR 4.x-2.x release versions:1.    Use the following command to check the status of I/C:sudo /etc/init.d/instance-controller status2.    Use the following command to restart the I/C if the status is down:sudo /etc/init.d/instance-controller startAnalyze log files to troubleshoot memory and disk issuesIf termination protection is turned on, use SSH to connect into the primary node. Then, review the instance-state log file.Analyze instance metrics such as memory and disk listed in the instant-state log. You can analyze these metrics using Linux commands such as free -m and df -h.Use the log file results to determine why the primary node is using a high amount of disk or memory.Troubleshoot primary node EC2 instance status check failuresDetermine if the primary instance status check failed by viewing the instance status check metrics.Troubleshoot the instance status check failure. Be aware that starting and stopping your EC2 instance results in EMR cluster termination.Troubleshoot primary nodes that have termination protection turned off and the cluster is already terminatedTurn on termination protection while launching a new EMR cluster.Switch to a larger instance type. For more information, see Supported instance types in Amazon EMR.Turn on Amazon CloudWatch alarms for EMR primary node memory and disk usageFollow"


Question: How can I resolve asymmetric routing issues when I create a VPN as a backup to Direct Connect in a transit gateway?

"I have an AWS Direct Connect connection. The Direct Connect gateway is associated with an AWS Transit Gateway. I created a Site to Site VPN as a backup to the Direct Connect connection, but have asymmetric routing issues. How can I resolve the asymmetric routing issues and maintain automatic failover with the AWS VPN?"

Answer: "I have an AWS Direct Connect connection. The Direct Connect gateway is associated with an AWS Transit Gateway. I created a Site to Site VPN as a backup to the Direct Connect connection, but have asymmetric routing issues. How can I resolve the asymmetric routing issues and maintain automatic failover with the AWS VPN?Short descriptionUsing a VPN connection as a backup to Direct Connect can result in asymmetric routing issues. Asymmetric routing occurs when network traffic enters through one connection and exits through another connection. Some network devices such as firewalls drop packets if the traffic received isn't logged in your stateful table.ResolutionFollow these best practices for configuring outbound and inbound network traffic.Best Practices for outbound traffic from AWS to your networkConfigure the VPN with dynamic routing using Border Gateway Protocol (BGP).Make sure your devices advertise the same prefixes from on-premises to AWS with the VPN and Direct Connect, or less specific VPN prefixes. For example, 10.0.0.0/16 is less specific compared to 10.0.0.0/24.AWS sets a higher preference value for Direct Connect over the VPN connection when sending on-premises traffic to your network if the prefix length received is the same value.For the AWS Transit Gateway, a static route pointing to a VPN attachment is more preferred to a dynamically propagated Direct Connect gateway route if the prefix length is the same value.For Direct Connect deployed with dynamic VPN as backup, AS PATH prepending isn't recommended. This is because if the prefixes are the same, Direct Connect routes are preferred regardless of the AS PATH prepend length.For more information, see Route tables and VPN priority.Best practices for inbound traffic from your network to AWSMake sure that your network device is configured to prefer sending return traffic through the Direct Connect connection.If the prefixes advertised from AWS to your network device are the same for Direct Connect and VPN, then the BGP local preference attribute can be used to force your device to send outbound traffic through the Direct Connect connection towards AWS. Set the Direct Connect path with a higher local preference value and a lower preference for VPN. For example, Local preference 200 for Direct Connect and 100 for VPN.Important:If the Direct Connect allowed prefix is summarized and routes advertised through VPN are more specific, then your network devices prefer the routes received through VPN.For example:The transit gateway propagated routes are VPC-A CIDR 10.0.0.0/16, VPC-B CIDR 10.1.0.0/16, and VPC-C 10.2.0.0/16.The summarized prefix on the Direct Connect gateway allowed prefixes is 10.0.0.0/14 in order to accommodate the 20 prefixes limit.Direct Connect advertises the Direct Connect gateway prefix 10.0.0.0/14, and the VPN transit gateway advertises the /16 CIDRs for each VPC over VPN.To resolve this issue, insert the summarized Direct Connect gateway route into the transit gateway route table. For example, add a static route 10.0.0.0/14 pointing to a VPC attachment. This makes sure that the transit gateway advertises the summarized network over VPN. Your network devices receive the same prefix from Direct Connect and VPN. Then, configure your gateway to filter out the specific prefixes received to make sure that only the summarized prefix is installed in the routing table from the VPN peer. There are different options available to filter out routes depending on the vendor specifications. For example, route-maps, prefix-lists, router-filter-lists, and so on.Traffic from your network to AWS reaches the transit gateway route table and the gateway does a lookup to select the most specific routes from each VPC attachment. For example:Attachment A pointing to VPC-A CIDR is 10.0.0.0/16.Attachment B pointing to VPC-B CIDR is 10.1.0.0/16.Attachment C pointing to VPC-C CIDR is 10.2.0.0/16.Related informationAWS Site to Site VPN routingAmazon VPC route table priorityHow do I configure Direct Connect and VPN failover with Transit Gateway?Follow"


Question: I'm receiving a "Kernel panic" error after I've upgraded the kernel or tried to reboot my EC2 Linux instance. How can I fix this?

"I completed a kernel or system upgrade or after a system reboot on my Amazon Elastic Compute Cloud (Amazon EC2) instance. Now the instance fails to boot and the following message appears:"VFS: Cannot open root device XXX or unknown-block(0,0)Please append a correct "root=" boot option; here are the available partitions:Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)""

Answer: "I completed a kernel or system upgrade or after a system reboot on my Amazon Elastic Compute Cloud (Amazon EC2) instance. Now the instance fails to boot and the following message appears:"VFS: Cannot open root device XXX or unknown-block(0,0)Please append a correct "root=" boot option; here are the available partitions:Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)"Short descriptionYour instance might fail to boot and show the kernel panic error message for the following reasons:The initramfs or initrd image is missing from the newly updated kernel configuration in /boot/grub/grub.conf. Or, the initrd or initramfs file itself is missing from the /boot directory.The kernel or system packages weren't fully installed during the upgrade process due to insufficient space.Third-party modules are missing from the initrd or initramfs image. For example, NVMe, LVM, or RAID modules.ResolutionThe initramfs or initrd image is missing from the /boot/grub/grub.conf or /boot directoryUse one of the following methods to correct this:Method 1: Use the EC2 Serial ConsoleIf you turned on EC2 Serial Console for Windows, then you can use it to troubleshoot supported Nitro-based instance types. The serial console helps you troubleshoot boot issues, network configuration, and SSH configuration issues. The serial console connects to your instance without the need for a working network connection. You can access the serial console using the Amazon EC2 console or the AWS Command Line Interface (AWS CLI).Before using the serial console, grant access to it at the account level. Then, create AWS Identity and Access Management (IAM) policies granting access to your IAM users. Also, every instance using the serial console must include at least one password-based user. If your instance is unreachable and you haven't configured access to the serial console, follow the instructions in Method 2: Use a rescue instance. For information on configuring the EC2 Serial Console for Linux, see Configure access to the EC2 Serial Console.Note: If you receive errors when running AWS CLI commands, make sure that you're using the most recent version of the AWS CLI.Method 2: Use a rescue instanceWarning:This procedure requires a stop and start of your EC2 instance. Be aware that if your instance is instance store-backed or has instance store volumes containing data, the data is lost when you stop the instance. For more information, see Determine the root device type of your instance.If you launch instances using EC2 Auto Scaling, stopping the instance might terminate the instance. Some AWS services use EC2 Auto Scaling to launch instances, such as Amazon EMR, AWS CloudFormation, and AWS Elastic Beanstalk. Check the instance scale-in protection settings for your Auto Scaling group. If your instance is part of an Auto Scaling group, temporarily remove the instance from the Auto Scaling group before starting the resolution steps.When you stop and start an instance, the public IP address of your instance changes. It's a best practice to use an Elastic IP address instead of a public IP address when routing external traffic to your instance.1.    Open the Amazon EC2 console.2.    Choose Instances from the navigation pane, and then select the impaired instance.3.    Choose Actions, Instance State, Stop instance.4.    In the Storage tab, select the Root device, and then select the Volume ID.Note: You can create a snapshot of the root volume as a backup before proceeding to step 5.5.    Choose Actions, Detach Volume (/dev/sda1 or /dev/xvda), and then choose Yes, Detach.6.    Verify that the State is Available.7.    Launch a new EC2 instance in the same Availability Zone and with the same operating system and same kernel version as the original instance. You can install the appropriate kernel version after the initial launch and then perform a reboot. This new instance is your rescue instance.8.    After the rescue instance launches, choose Volumes from the navigation pane, and then select the detached root volume of the original instance.9.    Choose Actions, Attach Volume.10.    Select the rescue instance ID (1-xxxx) and then enter /dev/xvdf.11.     Run the following command to verify that the root volume of the impaired instance attached to the rescue instance successfully:$ lsblkThe following is an example of the output:NAME    MAJ:MIN   RM  SIZE RO TYPE MOUNTPOINTxvda    202:0     0   15G  0  disk└─xvda1 202:1     0   15G  0  part /xvdf    202:80    0   15G  0  disk└─xvdf1 202:0     0   15G  0  part12.    Create a mount directory and then mount under /mnt.$ mount -o nouuid /dev/xvdf1 /mntInvoke a chroot environment by running the following command:$ for i in dev proc sys run; do mount -o bind /$i /mnt/$i; done14.    Run the chroot command on the mounted /mnt file system:$ chroot /mntNote: The working directory is changed to "/".15.    Run the following commands based on your operating system.RPM-based operating systems:$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg$ sudo dracut -f -vvvvvDebian-based operating systems:$ sudo update-grub && sudo update-grub2$ sudo update-initramfs -u -vvvvv16.    Verify that the initrd or initramfs image is present in the /boot directory and that the image has a corresponding kernel image. For example, vmlinuz-4.14.138-114.102.amzn2.x86_64 and initramfs-4.14.138-114.102.amzn2.x86_64.img.17.    After verifying that the latest kernel has a corresponding initrd or initramfs image, run the following commands to exit and cleanup the chroot environment:$ exitumount /mnt/{dev,proc,run,sys,}18.    Detach the root volume from the rescue instance and attach the volume to the original instance.19.    Start the original instance.The kernel or system package wasn't fully installed during an updateRevert to a previous kernel version. For instructions, see How do I revert to a known stable kernel after an update prevents my Amazon EC2 instance from rebooting successfully?Third-party modules are missing from the initrd or initramfs imageInvestigate to determine what module or modules are missing from the initrd or initramfs image. Then verify if you can add the module back to the image. In many cases, it's easier to rebuild the instance.The following is example console output from an Amazon Linux 2 instance running on the Nitro platform. The instance is missing the nvme.ko module from the initramfs image:dracut-initqueue[1180]: Warning: dracut-initqueue timeout - starting timeout scriptsdracut-initqueue[1180]: Warning: Could not boot.[  OK  ] Started Show Plymouth Boot Screen.[  OK  ] Reached target Paths.[  OK  ] Reached target Basic System.dracut-initqueue[1180]: Warning: /dev/disk/by-uuid/55da5202-8008-43e8-8ade-2572319d9185 does not existdracut-initqueue[1180]: Warning: Boot has failed. To debug this issue add "rd.shell rd.debug" to the kernel command line.Starting Show Plymouth Power Off Screen...To determine if the kernel panic error is caused by a missing third-party module or modules, do the following:1.    Use Method 1: Use the EC2 Serial Console in the preceding section to create a chroot environment in root volume of the non-booting instance.-or-Follow steps 1-14 in Method 2: Use a rescue instance in the preceding section to create a chroot environment in the root volume of the non-booting instance.2.    Use one of the following three options to determine which module or modules are missing from the initramfs or initrd image:Option 1: Run the dracut -f -v command in the /boot directory to determine if rebuilding the initrd or initramfs image fails. Also use the dracut -f -v command to list which module or modules is missing.Note: The dracut -f -v command might add any missing modules to the initrd or intramifs image. If the command doesn't find errors, try to reboot the instance. If the instance reboots successfully, then the command resolved the error.Option 2: Run the lsinitrd initramfs-4.14.138-114.102.amzn2.x86_64.img | less command to view the contents of the initrd or initramfs file. Replace initramfs-4.14.138-114.102.amzn2.x86_64.img with the name of your image.Option 3: Inspect the /usr/lib/modules directory.3.     If you find a missing module, you can try to add it back to the kernel. For information on how to obtain and add modules into the kernel, see the documentation specific to your Linux distribution.Follow"


Question: Why can't I see or play call recordings after setting up the Amazon Connect CTI Adapter for Salesforce?

"I can't see or play call recordings in Salesforce after setting up the Amazon Connect CTI Adapter. I configured the AmazonConnectSalesforceLambda Serverless Application Repository package, but it's not working as expected. How do I troubleshoot the issue?"

Answer: "I can't see or play call recordings in Salesforce after setting up the Amazon Connect CTI Adapter. I configured the AmazonConnectSalesforceLambda Serverless Application Repository package, but it's not working as expected. How do I troubleshoot the issue?Short descriptionIf the AmazonConnectSalesforceLambda Serverless Application Repository package isn't configured correctly, then calls recorded in Amazon Connect won't display or play in Salesforce.Two types of call recording and playback issues can occur when the AmazonConnectSalesforceLambda Serverless Application Repository package is misconfigured.The Contact Channel Analytics object isn't being created in the Salesforce dashboard.The Contact Channel Analytics object is created in Salesforce, but recordings are either not displaying or not playing.To troubleshoot call recordings not displaying or playing in Salesforce after setting up the Amazon Connect CTI Adapter, do the following:Verify that you've deployed the correct AmazonConnectSalesforceLambda Serverless Application Repository package for the Amazon Connect CTI Adapter version that you're using.Verify that you've deployed the AmazonConnectSalesforceLambda Serverless Application Repository package with the correct parameters.Verify that call recording streaming is activated in your AWS CloudFormation stack.Verify that call recording streaming is activated in your Amazon Connect contact flow.Verify that non-admin users are added to the AC_CallRecording permission set in Salesforce.Verify that the agent cleared the After Contact Work (ACW) state before they tried to playback the call recording.Verify that the Lambda functions in your AmazonConnectSalesforceLambda Serverless Application Repository package are invoking.Review the network calls made on the Salesforce dashboard to identify and troubleshoot any networking errors.For more information, see the following sections in the Amazon Connect CTI Adapter for Salesforce Lightning Installation Guide on GitHub:Setting up the Salesforce Lambdas manuallyCall recording streamingResolutionVerify that you've deployed the correct AmazonConnectSalesforceLambda Serverless Application Repository package for the Amazon Connect CTI Adapter version that you're usingThe Serverless Application Repository package won't work as expected if the version is different than the Amazon Connect CTI Adapter version that you're using.To upgrade from an earlier Amazon Connect CTI Adapter version, see Upgrading from an earlier version.Note: It's a best practice to upgrade the Amazon Connect CTI Adapter version, rather than installing earlier versions. If you choose to install an earlier version, make sure that you refer to the specific documentation for that version.Verify that you've deployed the AmazonConnectSalesforceLambda Serverless Application Repository package with the correct parametersIf the Serverless Application Repository package is deployed with incorrect parameters, it can cause its associated AWS Lambda functions to fail or not invoke as expected.To review and confirm your required parameters, follow the instructions in Setting up the Salesforce Lambdas manually.Verify that call recording streaming is activated in your AWS CloudFormation stackMake sure that the PostcallRecordingImportEnabled parameter is set to true in your AWS CloudFormation stack.For instructions, see Viewing stack information in the CloudFormation User Guide.Verify that call recording streaming is activated in your Amazon Connect contact flow1.    Be sure that the Set recording and analytics behavior contact block in your Amazon Connect contact flow has the Recording setting turned to On. For instructions, see How to set up recording behavior.2.    Make sure that the Set contact attributes contact block has the postcallRecordingImportEnabled setting configured as true.Note: You can verify the recordings appear in your Amazon Connect instance by reviewing the Contact Search page in the Amazon Connect console.Verify that non-admin users are included on the AC_CallRecording permission set in SalesforceNon-admin users must be added to the AC_CallRecording permission set in Salesforce to use call recording streaming.For instructions, see Adding users to the AC_CallRecording permission set.If you're using Amazon Connect CTI Adapter version 5.16+Also verify the following:The non-admin users are logged in to the Amazon Connect instance.The non-admin users have the required security profile permissions to access the recordings.Verify that the agent cleared ACW state before they tried to playback the call recordingAgents must clear ACW state before a Contact Trace Record (CTR) can be added to your Kinesis data stream.To view agents' past statuses, review your Amazon Connect instance's  real-time metrics report.Verify that the Lambda functions in your AmazonConnectSalesForceLambda Serverless Application Repository package are invokingTo view the aggregate metrics for the resources in your Serverless Application Repository package, do the following:1.    Open the Lambda console Applications page.2.    Choose serverlessrepo-AmazonConnectSalesforceLambda.3.    Choose Monitoring.If you don't see invocations for any of the associated Lambda functions1.    Verify that you're exporting contact records from Amazon Connect using the right Kinesis data stream. For instructions, see Activate data streaming for your instance.2.    Be sure that the correct Kinesis stream Amazon Resource Name (ARN) is configured in your CloudFormation stack. For instructions, see Viewing stack information in the CloudFormation User Guide.3.    Verify that the Kinesis trigger is activated for the serverlessrepo-xxxx-sfCTRTrigger-xxxx Lambda function.For more information, see Activate data streaming for your instance in the Amazon Connect Administrator Guide.If you do see invocations for the associated Lambda functionsReview each function's Amazon CloudWatch Logs to identify and resolve any Lambda function errors.For more information, see How do I troubleshoot Lambda function failures?Note: If one of your Lambda functions returns an Invalid credentials error, do the following:Verify that the correct Salesforce credentials are stored in AWS Secrets Manager. For instructions, see Store Salesforce credentials in AWS Secrets Manager.Verify that the SalesforceUsername and SalesforceHost parameters are configured correctly in the AWS CloudFormation stack. For instructions, see Viewing stack information in the CloudFormation User Guide.The following are the Lambda functions associated with creating the Contact Channel Analytics object:serverlessrepo-xxxx-sfCTRTrigger-xxxx is invoked by the Kinesis stream and processes the incoming CTRs. Based on its configuration, it calls other Lambda functions in the package.serverlessrepo-xxxx-sfContactTraceRecord-xxxx processes the CTR event.serverlessrepo-xxxx-sfExecuteTranscriptionSt-xxxx checks the CTR to see if the recording import or transcription is activated.serverlessrepo-xxxx-sfInvokeAPI-xxxx creates and accesses objects in the Salesforce dashboard by calling the Salesforce API.Review the network calls made on the Salesforce dashboard to identify and troubleshoot any networking errorsCreate an HTTP Archive (HAR) file that reproduces the call recording or playback issue. Then, use the HAR file from your browser to identify and troubleshoot any potential networking issues.Related informationManaging applications in the AWS Lambda consoleIntelligent case management using Amazon Connect and Amazon Kinesis Data Streams (AWS Blog)Follow"


Question: How do I troubleshoot the error "javasqlSQLException: No more data to read from socket" when I'm trying to connect to my Amazon RDS for Oracle instance?

I get the error "javasqlSQLException: No more data to read from socket" when I try to connect to my Amazon Relational Database Service (Amazon RDS) for Oracle DB instance.

Answer: "I get the error "javasqlSQLException: No more data to read from socket" when I try to connect to my Amazon Relational Database Service (Amazon RDS) for Oracle DB instance.ResolutionYou get the error “javasqlSQLException: No more data to read from socket“ because of a connectivity issue between the Oracle server and the client JDBC driver. The most common reasons and troubleshooting options for these connection failures are the following:The connection is abruptly terminated due to network interruptions: To troubleshoot this issue, check the alert.log file of the instance for any TNS timeout errors posted during the time when the connection timed out from the application end. For more information, see Oracle documentation for TNS timeout errors. For more information on accessing the alert log for RDS instances, see Oracle database log files.The connection is terminated because of Oracle errors on the server side: Check the alert.log file for ORA-0600 or ORA-07445 errors. Collect the trace dump for specific Oracle errors. Check if these errors have a known fix provided by Oracle support.The client-server connection is not active: To troubleshoot this issue, set the parameter SQLNET.EXPIRE_TIME to a specified interval, in minutes, to send a probe that verifies that the client-server connections are active. For more information, see Oracle documentation for SQLNET. EXPIRE_TIME.The RDS for Oracle instance is not available or was restarted when the JDBC client was trying to use an existing connection to the Oracle server: To troubleshoot this issue, retrieve events for the RDS instance and check if the instance was restarted or stopped when the connections were established from the JDBC client.The JDBC drivers used for connecting to the RDS for Oracle Instance are incompatible: To troubleshoot this issue, confirm that the version of JDBC driver is compatible with that of the DB instance. For the list of compatible JDBC drivers, see Oracle documentation for Compatibility matrix for Java machines and JDBC drivers used with ODI. If the JDBC driver is incompatible, download the latest JAR file in your source code. Then, include this file in your classpath when you compile the class that creates connections to the database. For more information, see Downloading the JDBC driver.The memory components on the client side cause timeouts: To troubleshoot this issue, check if the Oracle Data Integrator has memory components on the client side that cause unwanted timeouts. Be sure that you set the correct values for these components on the client side. For more information, see Oracle documentation for How to define Java options (such as the limits of memory heap, the location of non-Java libraries, etc.) in ODI.Related informationOracle documentation for A "No More Data to Read From Socket" error has been signaled from an ODI integration interfaceFollow"


Question: How do I resolve the CloudHSM error "InitializeCluster request failed: CloudHsmInvalidRequestException - TrustAnchor provided is not a valid x509 certificate"?

"I tried to initialize an AWS CloudHSM cluster, and received the error "InitializeCluster request failed: CloudHsmInvalidRequestException - TrustAnchor provided is not a valid x509 certificate.""

Answer: "I tried to initialize an AWS CloudHSM cluster, and received the error "InitializeCluster request failed: CloudHsmInvalidRequestException - TrustAnchor provided is not a valid x509 certificate."ResolutionYou must use a self-signed root certificate (customerCA.crt) to sign the cluster certificate signing request (CSR). Verify that the certificate is an issuing certificate or trust anchor root certificate with the following AWS CLI command:Note: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.$ openssl x509 -in customerCA.crt -text -nooutIf the certificate customerCA.crt is a root certificate, then the issuer and subject are the same.For more information, see Sign the CSR.Related informationWhat is AWS CloudHSM?Follow"


Question: What are some best practices for implementing Lambda-backed custom resources with CloudFormation?

I want to follow best practices when implementing AWS Lambda-backed custom resources with AWS CloudFormation.

Answer: "I want to follow best practices when implementing AWS Lambda-backed custom resources with AWS CloudFormation.ResolutionConsider the following best practices when implementing AWS Lambda-backed custom resources with AWS CloudFormation.Build your custom resources to report, log, and handle failureExceptions can cause your function code to exit without sending a response. CloudFormation requires an HTTPS response to confirm whether the operation is a success or a failure. An unreported exception causes CloudFormation to wait until the operation times out before starting a stack rollback. If the exception reoccurs during rollback, then CloudFormation waits again for a timeout before it ends in a rollback failure. During this time, your stack is unusable.To avoid timeout issues, include the following in the code that you create for your Lambda function:Logic to handle exceptionsThe ability to log the failure for troubleshooting scenariosThe ability to respond to CloudFormation with an HTTPS response confirming that an operation failedA dead-letter queue that lets you capture and deal with incomplete runsA cfn-response module to send a response to CloudFormationSet reasonable timeout periods, and report when they're about to be exceededIf an operation doesn't run within its defined timeout period, then the function raises an exception and no response is sent to CloudFormation.To avoid this issue, consider the following:Set the timeout value for your Lambda functions high enough to handle variations in processing time and network conditions.Set a timer in your function to respond to CloudFormation with an error when a function is about to time out. A timer can help prevent delays for custom resources.Build around Create, Update, and Delete eventsDepending on the stack action, CloudFormation sends your function a Create, Update, or Delete event. Because each event is handled differently, make sure that there are no unintended behaviors when any of the three event types is received.For more information, see Custom resource request types.Understand how CloudFormation identifies and replaces resourcesWhen an update initiates the replacement of a physical resource, CloudFormation compares the PhysicalResourceId that your Lambda function returns to the previous PhysicalResourceId. If the IDs differ, then CloudFormation assumes that the resource is replaced with a new physical resource.However, to allow for potential rollbacks, the old resource isn't implicitly removed. When the stack update is successfully completed, a Delete event request is sent with the old physical ID as an identifier. If the stack update fails and a rollback occurs, then the new physical ID is sent in the Delete event.Use PhysicalResourceId to uniquely identify resources so that when a Delete event is received, only the correct resources are deleted during a replacement.Design your functions with idempotencyAn idempotent function can be repeated numerous times with the same inputs, and the result is the same as doing it only once. Idempotency makes sure that retries, updates, and rollbacks don't create duplicate resources or introduce errors.For example, CloudFormation invokes your function to create a resource, but doesn't receive a response that the resource is successfully created. CloudFormation might invoke the function again, and create a second resource. The first resource can then become orphaned.Implement your handlers to correctly handle rollbacksWhen a stack operation fails, CloudFormation attempts to roll back and revert all resources to their prior state. This results in different behaviors depending on whether the update caused a resource replacement.To make sure that rollbacks are successfully completed, consider the following:Avoid implicitly removing old resources until a Delete event is received.Use accustom or the Custom Resource Helper on the GitHub website to help you follow best practices when using custom resources in CloudFormation.Related informationCustom resourcesFollow"


Question: What are the best practices for using multiple Network Load Balancers with an endpoint service?

I want to use multiple Network Load Balancers with an endpoint service.

Answer: "I want to use multiple Network Load Balancers with an endpoint service.ResolutionWhen you associate multiple Network Load Balancers with an endpoint service, the endpoint interface connects to only one Network Load Balancer per Availability Zone. To make sure that all endpoint consumers have a consistent service experience, use the same configuration across your Network Load Balancers.It's a best practice to identically configure the following items for each of your Network Load Balancers:Listener port and protocolTarget groups and targetsThe application that runs on the target instancesRelated informationWhat is a Network Load Balancer?Access an AWS service using an interface VPC endpointFollow"


Question: Why did Amazon EC2 terminate my Spot Instance?

"I launched a Spot Instance but now I can't find it in the Amazon Elastic Compute Cloud (Amazon EC2) console. Or, my Amazon EMR node Spot Instance was terminated."

Answer: "I launched a Spot Instance but now I can't find it in the Amazon Elastic Compute Cloud (Amazon EC2) console. Or, my Amazon EMR node Spot Instance was terminated.ResolutionAmazon EC2 can interrupt your Spot Instance at any time with a two-minute notice for the following reasons:Lack of Spot capacity: Amazon EC2 can interrupt your Spot Instance when its capacity is required. Usually, Amazon EC2 reclaims your instance to repurpose capacity. Amazon EC2 might also terminate your Spot Instance for issues such as host maintenance or hardware decommission.Amazon EC2 can't meet your Spot Instance request constraints: Some Spot requests include a constraint, such as a launch group or a specific Availability Zone group. The Spot Instances are terminated as a group when the constraint can no longer be met.The Spot Price is higher than the maximum price that you set: When you request a Spot Instance, you can specify a maximum price for the instance. By default, this maximum price is equal to the On-Demand pricing for that instance type. When the Spot Price increases beyond your set maximum price, your Spot Instance is interrupted. If the interruption behavior is "stop" or "hibernate", your Spot Instance starts again when the Spot price reduces to under your maximum price. Setting a high maximum price doesn't mean that a Spot Instance is available. For more information, see How Spot Instances work.Because of these interruptions, it's a best practice to use Spot Instances for workloads that are stateless, fault-tolerant, and flexible enough to withstand interruptions.Note: When Amazon EC2 interrupts a Spot Instance, the Spot Instance is terminated by default. You can change this default behavior to hibernate, or you can stop the instance instead of terminating it. For more information, see Spot Instance interruptions.To determine why Amazon EC2 interrupted your Spot Instance, do the following:Open the Amazon EC2 console, and then select Spot Requests.Select the Request ID of the terminated Spot Instance.View the Status field under the Description section to see the reason code for why the instance was terminated. For example, if Amazon EC2 didn’t have enough Spot Capacity, the Status field says "instance-terminated-no-capacity". For a complete list of reason codes, see Spot request status codes.You can use Spot Instance interruption notices to work around potential interruptions. For more information, see Taking advantage of Amazon EC2 Spot Instance interruption notices.Related informationSpot request statusSpot Instance best practicesWhy is my Spot Instance terminating even though the maximum price is higher than the Spot price?When should you use Spot Instances - Amazon EMR documentationFollow"


Question: How do I use table statistics to monitor an AWS DMS task?

How do I use table statistics to monitor an AWS Database Migration Service (AWS DMS) task?

Answer: "How do I use table statistics to monitor an AWS Database Migration Service (AWS DMS) task?ResolutionOpen the AWS DMS console, and then choose Database migration tasks.Choose the name of the task that you want to monitor.Note: If your table had an issue that you corrected, select the table, and then choose Reload table data. This action reloads one or more tables, so you don't have to restart the task.From the Table statistics section, you can view column details for your table.The Load state column has the following states:Table does not exist: AWS DMS can't find the table on the source endpoint.Before load: The full load process is enabled, but it hasn't started yet.Full load: The full load process is in progress.Table completed: Full load is completed.Table cancelled: Loading of the table is canceled.Table error: An error occurred when loading the table.The Inserts, Deletes, Updates, and DDLs columns show the number of these statements that were replicated during the change data capture (CDC) phase.The Full load rows column shows the total number of rows that were migrated during the full load phase.The Total column shows the total number of rows that were migrated during the full load and the applied Insert, Update, or Delete statements during the CDC phase.The Validation state column shows the state of the validation, such as Not enabled, Pending records, Validated, or Error.The Validation pending, Validation failed, and Validation suspended columns show the number of transactions for each transaction type. For example, this value represents the number of rows that failed validation, are suspended, or are in pending state. For more information, see Validating AWS DMS tasks.The Last updated column shows the date and time that the information contained in the table statistics tab was last updated.If you stop and restart a task, the table statistics are reset. For example, if you perform a CDC with entries for inserts, updates, and deletes, stopping and resuming a task resets the count to 0.Related informationMonitoring AWS DMS tasksFollow"


Question: How do I troubleshoot and resolve high CPU utilization on my Amazon RDS for MySQL or Amazon Aurora MySQL instance?

I'm experiencing high CPU utilization on my Amazon Relational Database Service (Amazon RDS) for MySQL DB instances or my Amazon Aurora MySQL-Compatible Edition instances. How can I troubleshoot and resolve high CPU utilization?

Answer: "I'm experiencing high CPU utilization on my Amazon Relational Database Service (Amazon RDS) for MySQL DB instances or my Amazon Aurora MySQL-Compatible Edition instances. How can I troubleshoot and resolve high CPU utilization?Short descriptionIncreases in CPU utilization can be caused by several factors, such as user-initiated heavy workloads, multiple concurrent queries, or long-running transactions.To identify the source of the CPU usage in your Amazon RDS for MySQL instance, review the following approaches:Enhanced MonitoringPerformance InsightsQueries that detect the cause of CPU utilization in the workloadLogs with activated monitoringAfter you identify the source, you can analyze and optimize your workload to reduce CPU usage.ResolutionUsing Enhanced MonitoringEnhanced Monitoring provides a view at the operating system (OS) level. This view can help identify the cause of a high CPU load at a granular level. For example, you can review the load average, CPU distribution (system% or nice%), and OS process list.Using Enhanced Monitoring, you can check the loadAverageMinute data in intervals of 1, 5, and 15 minutes. A load average that's greater than the number of vCPUs indicates that the instance is under a heavy load. Also, if the load average is less than the number of vCPUs for the DB instance class, CPU throttling might not be the cause for application latency. Check the load average to avoid false positives when diagnosing the cause of CPU usage.For example, if you have a DB instance that's using a db.m5.2xlarge instance class with 3000 Provisioned IOPS that reaches the CPU limit, you can review the following example metrics to identify the root cause of the high CPU usage. In the following example, the instance class has eight vCPUs associated with it. For the same load average, exceeding 170 indicates that the machine is under heavy load during the timeframe measured:Load Average MinuteFifteen170.25Five391.31One596.74CPU UtilizationUser (%)0.71System (%)4.9Nice (%)93.92Total (%)99.97Note: Amazon RDS gives your workload a higher priority over other tasks that are running on the DB instance. To prioritize these tasks, workload tasks have a higher Nice value. As a result, in Enhanced Monitoring, Nice% represents the amount of CPU being used by your workload against the database.After turning on Enhanced Monitoring, you can also check the OS process list that's associated with the DB instance. Enhanced monitoring shows a maximum of 100 processes. This can help you identify which processes have the largest impact on performance based on CPU and memory use.In the operating system (OS) process list section of Enhanced Monitoring, review the OS processes and RDS processes. Confirm the percentage of CPU utilization of a mysqld or Aurora process. These metrics can help you confirm whether the increase in CPU utilization is caused by OS or by RDS processes. Or, you can use these metrics to monitor any CPU usage increases caused by mysqld or Aurora. You can also see the division of CPU utilization by reviewing the metrics for cpuUtilization. For more information, see Monitoring OS metrics with Enhanced Monitoring.Note: If you activate Performance Schema, then you can map the OS thread ID to the process ID of your database. For more information, see Why is my Amazon RDS DB instance using swap memory when I have sufficient memory?Using Performance InsightsYou can use Performance Insights to identify the exact queries that are running on the instance and causing high CPU usage. First, activate Performance Insights for MySQL. Then, you can use Performance Insights to optimize your workload. Be sure to consult with your DBA.To see database engines that you can use with Performance Insights, see Monitoring DB load with Performance Insights on Amazon RDS.Using queries to detect the cause of CPU utilization in the workloadBefore you can optimize your workload, you must identify the problematic query. You can run the following queries while the high CPU issue is occurring to identify the root cause of the CPU utilization. Then, optimize your workload to reduce your CPU usage.The SHOW PROCESSLIST command shows you the threads that are running currently on your MySQL instance. Sometimes, the same set of statements might continue running without completion. When this happens, the subsequent statements must wait for the first set of statements to finish. This is because InnoDB row-level locking might be updating the same rows. For more information, see SHOW PROCESSLIST statement on the MySQL website.SHOW FULL PROCESSLIST;Note: Run the SHOW PROCESSLIST query as the primary system user. If you're not the primary system user user, then you must have MySQL PROCESS server administration privileges to see all the threads running on a MySQL instance. Without admin privileges, SHOW PROCESSLIST shows only the threads associated with the MySQL account that you're using.The INNODB_TRX table provides information about all currently running InnoDB transactions that aren't read-only transactions.SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;The INNODB_LOCKS table provides information about locks that an InnoDB transaction has requested but hasn't received.For MySQL 5.7 or earlier:SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;For MySQL 8.0:SELECT * FROM performance_schema.data_locks;The INNODB_LOCK_WAITS table provides one or more rows for each blocked InnoDB transaction.For MySQL 5.7 or earlier:SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;For MySQL 8.0:SELECT * FROM performance_schema.data_lock_waits;You can run a query similar to the following to see the transactions that are waiting, and the transactions that are blocking the waiting transactions. For more information, see Using InnoDB transaction and locking information on the MySQL website.For MySQL 5.7 or earlier:SELECT  r.trx_id waiting_trx_id,  r.trx_mysql_thread_id waiting_thread,  r.trx_query waiting_query,  b.trx_id blocking_trx_id,  b.trx_mysql_thread_id blocking_thread,  b.trx_query blocking_queryFROM       information_schema.innodb_lock_waits wINNER JOIN information_schema.innodb_trx b  ON b.trx_id = w.blocking_trx_idINNER JOIN information_schema.innodb_trx r  ON r.trx_id = w.requesting_trx_id;For MySQL 8.0:SELECT  r.trx_id waiting_trx_id,  r.trx_mysql_thread_id waiting_thread,  r.trx_query waiting_query,  b.trx_id blocking_trx_id,  b.trx_mysql_thread_id blocking_thread,  b.trx_query blocking_queryFROM       performance_schema.data_lock_waits wINNER JOIN information_schema.innodb_trx b  ON b.trx_id = w.blocking_engine_transaction_idINNER JOIN information_schema.innodb_trx r  ON r.trx_id = w.requesting_engine_transaction_id;The SHOW ENGINE INNODB STATUS query provides information from the standard InnoDB monitor about the state of the InnoDB storage engine. For more information, see SHOW ENGINE statement on the MySQL website.SHOW ENGINE INNODB STATUS;The SHOW [GLOBAL | SESSION] STATUS provides information about the server status. For more information, see SHOW STATUS statement on the MySQL website.SHOW GLOBAL STATUS;Note: These queries were tested on Aurora 2.x (MySQL 5.7); Aurora 1. x (MySQL 5.6); MariaDB 10.x. Additionally, the INFORMATION_SCHEMA.INNODB_LOCKS table is no longer supported as of MySQL 5.7.14 and removed in MySQL 8.0. The performance_schema.data_locks table replaces the INFORMATION_SCHEMA.INNODB_LOCKS table. For more information, see The data_locks table on the MySQL website.Analyzing logs and turning on monitoringWhen you analyze logs or want to activate monitoring in Amazon RDS for MySQL, consider the following approaches:Analyze the MySQL General Query Log to view what the mysqld is doing at a specific time. You can also view the queries that are running on your instance at a specific time, including information about when clients connect or disconnect. For more information, see The General Query Log on the MySQL website.Note: When you activate the General Query Log for long periods, the logs consume storage and can add to performance overhead.Analyze the MySQL Slow Query Logs to find queries that take longer to run than the seconds that you set for long_query_time. You can also review your workload and analyze your queries to improve performance and memory consumption. For more information, see The Slow Query Log on the MySQL website. Tip: When you use Slow Query Log or General Query Log, set the parameter log_output to FILE.Use the MariaDB Audit Plugin to audit database activity. For example, you can track users that are logging on to the database or queries that are run against the database. For more information, see MariaDB Audit Plugin support.If you use Aurora for MySQL, then you can also use Advanced Auditing. Auditing can give you more control over the types of queries you want to log. Doing so reduces the overhead for logging.Use the innodb_print_all_deadlocks parameter to check for deadlocks and resource locking. You can use this parameter to record information about deadlocks in InnoDB user transactions in the MySQL error log. For more information, see innodb_print_all_deadlocks on the MySQL website.Analyzing and optimizing the high CPU workloadAfter you identify the query that's increasing CPU usage, optimize your workload to reduce the CPU consumption.If you see a query that's not required for your workload, you can terminate the connection using the following command:CALL mysql.rds_kill(processID);To find the processID of a query, run the SHOW FULL PROCESSLIST command.If you don't want to end the query, then optimize the query using EXPLAIN. The EXPLAIN command shows the individual steps involved in running a query. For more information, see Optimizing Queries with EXPLAIN on the MySQL website.To review profile details, activate PROFILING. The PROFILING command can indicate resource usage for statements that are running during the current session. For more information, see SHOW PROFILE statement on the MySQL website.To update any table statistics, use ANALYZE TABLE. The ANALYZE TABLE command can help the optimizer choose an appropriate plan to run the query. For more information, see ANALYZE TABLE statement on the MySQL website.Related informationAmazon RDS for MySQLAmazon RDS for MariaDBHow do I activate and monitor logs for an Amazon RDS MySQL DB instance?Tuning Amazon RDS for MySQL with Performance Insights Follow"


Question: How can I check to see who modified a Lambda function what changes were made?

I want to find out who modified an AWS Lambda function and what changes were made.

Answer: "I want to find out who modified an AWS Lambda function and what changes were made.ResolutionYou can use AWS CloudTrail to track which users are modifying Lambda functions and what changes were made. CloudTrail is turned on by default for your AWS account.For an ongoing record of events in your AWS account, create a trail. Using a trail, CloudTrail creates logs of API calls made on your account. These logs are delivered to an Amazon Simple Storage Service (Amazon S3) bucket that you specify. If you don't configure a trail, you can still view the most recent events in the CloudTrail console in Event history.Event history1.    Open the CloudTrail console.2.    In the navigation pane, choose Event history.3.    Follow the instructions for viewing, displaying, and filtering CloudTrail events for your use case.You can also download recorded event history as a file in CSV or JSON format.For an example CloudTrail log entry for the GetFunction and DeleteFunction API actions, see Understanding Lambda log file entries in the Lambda Developer Guide.Important: The eventName might include date and version information, such as "GetFunction20150331", but it's still referring to the same public API.For a list of all supported Lambda APIs, see Actions in the Lambda Developer Guide.CloudTrail logs1.    Open the CloudTrail console.2.    In the navigation pane, choose Trails.3.    Select the S3 bucket value for the trail that you want to view. The Amazon S3 console opens and shows that bucket, at the top level for the log files.4.    Choose the folder for the AWS Region where you want to review log files.5.    Navigate the bucket folder structure to the year, the month, and the day where you want to review logs of activity in that Region.6.    Select the file name, and then choose Download.7.    Unzip the file, and then use your favorite JSON file viewer to see the log.The log contains information about requests for resources in your account. For example, who made the request, the services used, and the actions performed. For more information, see Understanding Lambda log file entries.Related informationUsing AWS Lambda with AWS CloudTrailLogging Lambda API calls with CloudTrailHow do I know which user made a particular change to my AWS infrastructure?Follow"


Question: How do I troubleshoot issues related to tagging in ECS tasks?

I have an issue with Amazon Elastic Container Service (Amazon ECS) task tags. How do I troubleshoot this?

Answer: "I have an issue with Amazon Elastic Container Service (Amazon ECS) task tags. How do I troubleshoot this?ResolutionWhen setting tags with Amazon ECS, you might have the following issues:Your tags aren't propagated from service or task definition to tasks.Your tags have an outdated Amazon Resource Name (ARN) and resource ID format.You're unable to add tags to your ECS resources due to missing AWS Identity and Access Management (IAM) permissions or tag restrictions.You're unable to see ECS tags in the AWS Billing Dashboard.To troubleshoot these issues, do the following:Verify that PropagateTags parameter is used to propagate from service or task definitions to tasksThe PropagateTags parameter can be used to copy tags from the task definition or service to the task. This can be done when you're running a task or creating a service. This parameter is not turned on by default.You can check if the PropagateTags is being used in a specific service by running the following command in AWS CLI and replacing servicename, clustername, and region with the appropriate values:aws ecs describe-services --services <servicename> --cluster <clustername> --region <region> --query 'services[*].propagateTags' --output textTo configure tags to propagate from the service or task definition using CLI, see RunTask and CreateService API.To activate tag propagation using the console:Open the Amazon ECS console.Select the AWS Region for your ECS resource.In the navigation pane, select Task Definitions.Select the task definition from the resource list, and choose Actions. Then, choose Create Service or Run Task.In the Task tagging configuration, next to Propagate tags from, choose Service or Task definitions.Note: The default option is Do not propagate.To use tags in ECS using AWS CloudFormation, you need to declare the entity AWS::ECS::Service using the properties EnableECSManagedTags and PropagateTags with the value: SERVICE or TASK_DEFINITION.Note:Using ECS service tags related properties after stack creation in CloudFormation will require a stack update and resource replacement. That means the service will be deleted and recreated through CloudFormation.Using the PropagateTags parameter can only be done when you're running a task or creating a service. For more information, see RunTask and CreateService API.You have access to the same configurations for Scheduled tasks  as you do for tasks launched directly using the Amazon ECS RunTask API.Verify that you are using the new ARN formatTo be able to tag Amazon ECS resources, you must use the new Amazon Resource Name (ARNs) and IDs  formats.Example of the two formats:Old format: arn:aws:ecs:region:aws_account_id:service/service-nameNew format: arn:aws:ecs:region:aws_account_id:service/cluster-name/service-nameTo migrate your ECS deployment to the new ARN and resource ID format, see Migrating your Amazon ECS deployment to the new ARN and resource ID format.Note: Your existing resources will not receive the new ARN format while tagging until they are recreated.Review that the IAM entity has the required permissions and check tags restrictionsIf you are unable to add tags to your ECS service, do the following:Check CloudTrail events in CloudTrail console for TagResource events.If you see one of the following errors: AccessDenied or The tags cannot be updated at this time. Wait a few minutes and try again, then the IAM entity doesn't have the ecs:TagResource permissions.To solve this, add ecs:TagResource permissions to the IAM entities.Once the permissions have been added, retry adding the tags to ECS cluster.Confirm that your ECS tags are within the tags restrictions. To review tags restrictions, see Tag restrictions.Check if it is an AWS Billing and Cost Management issueTo verify that the required tags are present on ECS tasks level, run the following command in AWS CLI and replace value with the ARN:aws ecs list-tags-for-resource --resource-arn <value>To verify that the required tags are present on ECS tasks level using the console:Open the Amazon ECS console.Select the AWS Region for your ECS resource.In the navigation pane, select a resource type (for example, Clusters).Select the resource from the resource list and choose **Tags.**If tags exist, they will be listed.If you are looking for managed tags, then ECS-managed must be turned on. Verify the ECS-managed status by running the following command and replacing servicename, clustername, and region with the appropriate values:aws ecs describe-services --services <servicename> --cluster <clustername> --region <region> --query 'services[*].enableECSManagedTags' --output textThe command output will contain enableECSManagedTags value.You can activate ECS-managed tags while creating service or running task using CLI, for more information, see RunTask and CreateService API.To activate ECS-managed tags using the console:Open the Amazon ECS console.Select the AWS Region for your ECS resource.In the navigation pane, select Task Definitions.Select the task definition from the resource list, and choose Actions. Then, choose Create Service or Run Task.In the Task tagging configuration, choose Enable ECS managed tags.If tags used for billing are listed but can't be seen in AWS Cost Explorer, be sure that tags are activated from the Billing and Cost Management console. To activate Cost allocation tags, see Activating user-defined cost allocation tags.Note: Every tag that has to be viewed as a filter in the Cost Explorer needs to be activated. It can take up to 24 hours for tags to activate.Related informationAmazon ECS troubleshootingTagging your Amazon ECS resourcesFollow"


Question: How can I use system policies to control access to my EFS file system?

I want to access my Amazon Elastic File System (Amazon EFS) file system across accounts so that I can share files. How can I do this using AWS Identity and Access Management (IAM) authorization for NFS clients and EFS access points?

Answer: "I want to access my Amazon Elastic File System (Amazon EFS) file system across accounts so that I can share files. How can I do this using AWS Identity and Access Management (IAM) authorization for NFS clients and EFS access points?Short descriptionYou can mount your Amazon EFS file system by using IAM authorization for NFS clients and access points with the Amazon EFS mount helper. By default, the mount helper uses DNS to resolve the IP address of your mount target. So if you're mounting from another account or Amazon Virtual Private Cloud (Amazon VPC), you must resolve the Amazon EFS mount target IP manually.PrerequisitesThe VPCs of your NFS client and your EFS file system are connected using either a VPC peering connection or a VPC Transit Gateway. This allows Amazon Elastic Compute Cloud (Amazon EC2) instances from the same or different accounts, to access EFS file systems in a different VPC.Your IAM role (instance role or any other role) has console or read access on both the Amazon EFS and NFS client resources.The Amazon EFS client and the botocore package are installed in the NFS client.ResolutionNote: If you receive errors when running AWS CLI commands, make sure that you're using the most recent version of the AWS Command Line Interface (AWS CLI).In this example, the EFS file system is present in account A and the NFS client is present in account B.    1.    To access and mount the cross account EFS file system, add a policy statement in the an IAM policy similar to this:{            "Sid": "EfsPermissions",            "Effect": "Allow",            "Action": [                "elasticfilesystem:ClientMount",                "elasticfilesystem:ClientWrite",                "elasticfilesystem:ClientRootAccess"            ],            "Resource": "arn:aws:elasticfilesystem:region:account-id:file-system/file-system-id"        }This statement allows the IAM role to have mount, write and root access on the EFS file system. If your NFS client is an EC2 instance, attach the IAM role to the instance.2.    Or, you can assume the role using the AWS CLI. Note that the AWS CLI can't resolve the DNS of an EFS file system present in another VPC. So, first determine the right mount target IP for your client. Then, configure the client to mount the EFS file system using that IP.To be sure of high availability, always use the mount target IP address in the same Availability Zone (AZ) as your NFS client. AZ name mappings might differ between accounts. Because you're mounting an EFS file system in another account, the NFS client and the mount target must be in the same AZ ID.To determine the AZ of your EC2 instance, call the DescribeAvailabilityZone API using one of these methods:Log in to the Amazon EC2 console, and choose Instances. Choose, EC2-Instance-ID, and then choose Networking. Under Networking details, you can find the Availability zone.-or-Run a command similar to this from the IAM entity that has sufficient read permissions for Amazon EC2 and get a similar output :$ aws ec2 describe-availability-zones --zone-name `curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone`{    "AvailabilityZones": [        {            "State": "available",             "ZoneName": "us-east-2b",             "Messages": [],             "ZoneId": "use2-az2",             "RegionName": "us-east-2"        }    ]}3.    To determine the mount target IP for the local AZ, all the DescribeMountTargets API using one of these methods:Log in to the Amazon EFS console, and choose File Systems. Choose, EFS-File-System-ID, and then under Network, note the IP address for your Availability zone.-or-Run a command similar to this from the IAM entity that has sufficient read permissions for Amazon EC2 and get a similar output :$ aws efs describe-mount-targets --file-system-id fs-cee4feb7{    "MountTargets": [        {            "MountTargetId": "fsmt-a9c3a1d0",             "AvailabilityZoneId": "use2-az2",             "NetworkInterfaceId": "eni-048c09a306023eeec",             "AvailabilityZoneName": "us-east-2b",             "FileSystemId": "fs-cee4feb7",             "LifeCycleState": "available",             "SubnetId": "subnet-06eb0da37ee82a64f",             "OwnerId": "958322738406",             "IpAddress": "10.0.2.153"        }, ...        {            "MountTargetId": "fsmt-b7c3a1ce",             "AvailabilityZoneId": "use2-az3",             "NetworkInterfaceId": "eni-0edb579d21ed39261",             "AvailabilityZoneName": "us-east-2c",             "FileSystemId": "fs-cee4feb7",             "LifeCycleState": "available",             "SubnetId": "subnet-0ee85556822c441af",             "OwnerId": "958322738406",             "IpAddress": "10.0.3.107"        }    ]}4.    From the output you get, note the IP address that corresponds to the mount target in the AZ of the EC2 instance.5.    Use the IP address you obtained and add the hosts entry in the /etc/hosts file in the NFS client. The format of the DNS name is mount-target-IP-Address file-system-ID.efs.region.amazonaws.com.See this example command:$ echo "10.0.2.153 fs-cee4feb7.efs.us-east-2.amazonaws.com" | sudo tee -a /etc/hosts6.    Mount the EFS file system using the mount helper.Note: In a cross-account scenario, you can't use the usual NFS command, so botocore and the Amazon EFS client is necessary.After following these steps, you are able to mount the EFS file system and start using it. If you experience any errors, see the troubleshooting guide.Related informationCreating file system policiesFollow"


Question: How do I create an AWS access key?

"I need an AWS access key to allow a program, script, or developer to have programmatic access to the resources on my AWS account."

Answer: "I need an AWS access key to allow a program, script, or developer to have programmatic access to the resources on my AWS account.ResolutionAn access key grants programmatic access to your resources. This means that you must guard the access key as carefully as the AWS account root user sign-in credentials.It's a best practice to do the following:Create an IAM user, and then define that user's permissions as narrowly as possible.Create the access key under that IAM user.For more information, see What are some best practices for securing my AWS account and its resources?Related informationBest practices for managing AWS accountsAccess management for AWS resourcesFollow"


Question: How do I troubleshoot throttling errors in Kinesis Data Streams?

"My Amazon Kinesis data stream is throttling. However, the stream didn't exceed the data limits. How do I detect "Rate Exceeded" or "WriteProvisionedThroughputExceeded" errors?"

Answer: "My Amazon Kinesis data stream is throttling. However, the stream didn't exceed the data limits. How do I detect "Rate Exceeded" or "WriteProvisionedThroughputExceeded" errors?Short DescriptionYou can detect and troubleshoot throttling errors in your Kinesis data stream by doing the following:Enable enhanced monitoring and compare IncomingBytes values.Log full records to perform stream count and size checks.Use random partition keys.Check for obscure metrics or micro spikes in Amazon CloudWatch metrics.ResolutionTo prevent "Rate Exceeded" or "WriteProvisionedThroughputExceeded" errors in your Kinesis data stream, try the following:Enable enhanced monitoring and compare IncomingBytes valuesTo verify whether you have hot shards, enable enhanced monitoring on your Kinesis data stream. When you enable shard level monitoring in a Kinesis data stream, then you can investigate the shards individually. You can examine the stream on a per shard basis to identify which shards are receiving more traffic or breaching any service limits.Note: Hot shards are often excluded from the Kinesis data stream metrics when the enhanced monitoring setting is disabled. For more information about hot shards, see Strategies for Resharding.You can also compare the IncomingBytes average and maximum values to verify whether there are hot shards in your stream. If enhanced monitoring is enabled, you can also see which specific shards deviate from the average.Log full records to perform stream count and size checksTo identify micro spikes or obscure metrics that breach stream limits, log full records or custom code to perform stream count and size checks. Then, evaluate the number and size of records that are sent to the Kinesis data stream. This can help you identify any spikes that breach data limits.You can also take the value from a one minute data point and divide it by 60. This gives you an average value per second to help determine if throttling is present within the time period specified. If the successful count doesn't breach the limits, then add the IncomingRecords metric to the WriteProvisionedThroughputExceeded metric, and retry the calculation. The IncomingRecords metric signals successful or accepted records, whereas the WriteProvisionedThroughputExceeded metric indicates how many records were throttled.Note: Check the sizes and number of records that are sent from the producer. If the combined total of the incoming and throttled records are greater than the stream limits, then consider changing the number of records.The PutRecord.Success metric is also a good indicator for operations that are failing. When there is a dip in the success metric, then investigate the data producer logs to find the root causes of the failures. If throttling occurs, establish logging on the data producer side to determine the total amount and size of submitted records. If the total number of records in the PutRecord.Success metric breaches the stream limits, then your Kinesis data stream throttles. For more information about Kinesis stream limits, see Kinesis Data Streams Quotas.Use random partition keysIf there are hot shards in your Kinesis data stream, use a random partition key to ingest your records. If the operations already use a random partition key, then adjust the key to correct the distribution. Then, monitor the key for changes in metrics such as IncomingBytes and IncomingRecords. If the maximum and average patterns are close together, then there are no hot shards.Check for obscure metrics or micro spikes in Amazon CloudWatch metricsIf there are CloudWatch metrics that don't clearly indicate breaches or micro spikes in the data, try the following solutions:Increase the number of shards, and then split the size of log records.Scale your Kinesis data stream to match the producer output.Use an exponential backoff and retry mechanism in the producer logic.Change the configuration settings for your producer so that your write rate is decreased.Limit the request rate of the producer and the number of records that are sent (per second) to match the capacity of the stream.For more information about stream quotas, see Kinesis Data Stream Quotas.Related InformationDeveloping and Using Custom Consumers with Dedicated Throughput (Enhanced Fan-Out)Monitoring the Amazon Kinesis Data Streams Service with Amazon CloudWatchFollow"


Question: How do I install an SSL/TLS certificate on my EC2 Windows instance running IIS server?

I want my web application or website running on an Amazon Elastic Compute Cloud (Amazon EC2) instance to use HTTPS. How do I install my own SSL certificate on an EC2 Windows instance running Internet Information Services (IIS) server to allow this?


Question: How can I customize my log files in Elastic Beanstalk?

"I want to customize my log files in AWS Elastic Beanstalk, and be sure that my custom application logs are included and streamed to Amazon CloudWatch."

Answer: "I want to customize my log files in AWS Elastic Beanstalk, and be sure that my custom application logs are included and streamed to Amazon CloudWatch.Short DescriptionIf the default log files that Elastic Beanstalk collects and streams don't meet the needs of your application or use case, then consider the following options to customize the collection and streaming of your log files:Include your custom logs in the log bundleRotate your logs(Optional) Stream your logs to CloudWatchNote: If you have a custom log file or if one of your logs is missing from the default logs, then you can further customize your log configuration.ResolutionInclude your custom logs in the log bundleWhen you request logs from Elastic Beanstalk, Elastic Beanstalk returns default log files from the Amazon Elastic Compute Cloud (Amazon EC2) instances in your environment. However, you might not receive these default log files if your application has a unique log location.To get Elastic Beanstalk to return your log files from a unique log location, extend the default log task configuration.Rotate your logsTo prevent your application log files from taking up too much disk space or even exhausting disk space, rotate your old log files with log rotation.Rotating your logs makes sure that old logs are deleted automatically from your environment's EC2 instances. If you want your old logs to persist, you can enable rotated logs to be uploaded to Amazon Simple Storage Service (Amazon S3) before the logs are deleted from an instance.(Optional) Stream your logs to CloudWatchIn production applications, it's a best practice to stream your logs to a remote storage solution, such as CloudWatch. To learn how to enable log streaming on Elastic Beanstalk, see Streaming Log Files to Amazon CloudWatch Logs or Using Elastic Beanstalk with Amazon CloudWatch Logs.If you want to stream custom log locations, see Instance Log Streaming Using Configuration Files.Streaming your logs to CloudWatch can help safeguard your data. For example, if your Elastic Beanstalk environment has a problem with an EC2 instance that terminates, then you can still recover your logs from CloudWatch. You can also use log rotation to protect against data loss.Related InformationWhat Is Amazon CloudWatch Logs?Troubleshooting CloudWatch Logs IntegrationStreaming Elastic Beanstalk Environment Health Information to Amazon CloudWatch LogsFollow"


Question: Why did my CloudWatch alarm trigger when its metric doesn't have any breaching data points?

"My Amazon CloudWatch alarm changed to the ALARM state. When I check the metric that's being monitored, the CloudWatch graph doesn't show any breaching datapoints. However, the Alarm History contains an entry with a breaching data point. Why did my CloudWatch alarm trigger?"

Answer: "My Amazon CloudWatch alarm changed to the ALARM state. When I check the metric that's being monitored, the CloudWatch graph doesn't show any breaching datapoints. However, the Alarm History contains an entry with a breaching data point. Why did my CloudWatch alarm trigger?Short descriptionCloudWatch alarms evaluate metrics based on the datapoints that are available at a given moment. Alarm History captures a record of the datapoints that the alarm evaluated at that timestamp. However, it's possible for new samples to be published after the alarm evaluation occurred. These new samples might impact the value that's calculated when CloudWatch aggregates the metric data.ResolutionFind the breaching datapointsIf your CloudWatch graph doesn't show any breaching datapoints, then those datapoints occurred outside of the alarm evaluation time. To understand how this happens, refer to the following example.In this example, X number of samples are available when an alarm evaluation occurs, resulting in an aggregated value of A. Later, new samples are posted, resulting in Y number of samples that are retrieved for the same timestamp. This results in a different aggregated value of B.In this situation, an alarm is configured with the following parameters:Namespace: Web_AppMetric: ResponseTimeDimension: host,h_04254448d4e964956Statistic: AverageThreshold: 0.005ComparisonOperator: GreaterThanThresholdPeriod: 60 seconds (1 minute)Evaluation Period: 1When the alarm evaluates the period from 12:00:00 - 12:01:00 UTC, the following values are retrieved by the metric:Sample-1: 12:00:00 UTC, numeric value: 0.00675Sample-2: 12:00:00 UTC, numeric value: 0.00789Sample-3: 12:00:00 UTC, numeric value: 0.00421The average of these values is 0.006283333, which breaches the threshold of 0.005 seconds. Therefore, the alarm changes to the ALARM state. The alarm's history captures the aggregated values that exceed the threshold.The host might temporarily experience a performance issue, which impacts the client application that's responsible for publishing metrics. As a result, the host might not post datapoints at equally spaced intervals. In this situation, samples for 12:00 were published after the alarm evaluation occurred. Below are all the samples for the 12:00 timestamp:Sample-1: 12:00:00 UTC, numeric value: 0.00675Sample-2: 12:00:00 UTC, numeric value: 0.00789Sample-3: 12:00:00 UTC, numeric value: 0.00421Sample-4: 12:00:00 UTC, numeric value: 0.00002Sample-5: 12:00:00 UTC, numeric value: 0.00007After receiving an alert from this alarm, the user renders a CloudWatch graph to review the metric behavior. CloudWatch retrieves the five samples from 12:00:00 - 12:01:00 UTC and aggregates them as an average of 0.003788. This is different from the previously calculated value and is below the threshold. Therefore, the breaching datapoints are not visible in the time range because additional samples were posted after the alarm evaluation occurred.Increase the Alarm Evaluation IntervalAn alarm's evaluation interval is the number of data points multiplied by the period. Configuring Datapoints to Alarm can result in a longer evaluation interval. When an alarm generates false alerts due to delayed metrics, increasing the evaluation interval allows delayed datapoints to be considered in the alarm evaluation. This reduces the number of false alerts.The evaluation interval can be increased by one of two ways:1.    Increase the period.In the following example, the period is increased to five minutes:Namespace: Web_AppMetric: ResponseTimeDimension: host,h_04254448d4e964956Statistic: AverageThreshold: 0.005ComparisonOperator: GreaterThanThresholdPeriod: 300 seconds (5 minutes)Evaluation Period: 1-or-2.    Configure "M out of N" Datapoints to Alarm.In the following example, M out of N datapoints are configured to two out of three.Namespace: Web_AppMetric: ResponseTimeDimension: host,h_04254448d4e964956Statistic: AverageThreshold: 0.005ComparisonOperator: GreaterThanThresholdPeriod: 60 seconds (1 minute)Evaluation Period (N): 3Datapoints To Alarm (M): 2When you configure Evaluation Periods and Datapoints to Alarm as different values, you set an "M out of N" alarm. Datapoints to Alarm is M and Evaluation Period is N. For example, if you configure four out of five data points with a period of one minute, then the evaluation interval is five minutes. Similarly, if you configure three out of three data points with a period of ten minutes, the evaluation interval is thirty minutes.With Datapoints to Alarm configured in this way, CloudWatch Alarms evaluate more data points. They also change the alarm state only when a minimum number of data points (M) breach a given set of data points (N). This parameter can adjust the alarm to trigger on a single datapoint or require multiple datapoints to transition to the ALARM state.For more information, see Create a CloudWatch alarm based on a static threshold and Configuring how CloudWatch alarms treat missing data.Related informationWhy didn't I receive an Amazon Simple Notification Service (Amazon SNS) notification for my CloudWatch alarm trigger?Why is my CloudWatch alarm in INSUFFICIENT_DATA state?Why did my CloudWatch alarm send me a notification after a single breached data point?Follow"


Question: How do I download AWS Site-to-Site VPN example configuration files?

I want to access AWS Site-to-Site VPN example configuration files. How can I do this?

Answer: "I want to access AWS Site-to-Site VPN example configuration files. How can I do this?Short descriptionTo download Site-to-Site VPN example configuration files, use the Download Configuration utility.There are two ways to access the Download Configuration utility:Amazon Virtual Private Cloud (Amazon VPC) consoleAWS Command Line Interface (AWS CLI)For a list of available example configuration files, see Example configuration files. Important: To use the Download Configuration utility, the following AWS Identity and Access Management (IAM) permissions are required:ec2:GetVpnConnectionDeviceTypesec2:GetVpnConnectionDeviceSampleConfigurationIf your IAM policy has an EC2 wildcard (*), you don't need to manually add these permissions. ResolutionTo access the Download Configuration utility from the Amazon VPC console1.    Open the Amazon VPC console.2.    In the left navigation pane, under VIRTUAL PRIVATE NETWORK (VPN), choose Site-to-Site VPN Connections.3.    Choose the name of your VPN connection.4.    Choose Download Configuration.5.    For Vendor, select your Customer Gateway device vendor.   -or-If your vendor isn't listed, select Generic. 6.    For Platform and Software, select the values that apply to your use case. 7.    For IKE Version, select the protocol version that applies to your use case.8.    Choose Download.The example configuration file downloads to your computer.To access the Download Configuration utility from the AWS CLINote: If you receive errors when running AWS CLI commands, make sure that you're using the most recent version of the AWS CLI.1.    List all available device configuration example files and get the VpnConnectionDeviceTypeId for your device by running the following get-vpn-connection-device-types command: Important: Replace <aws-region> with your AWS Region. aws ec2 get-vpn-connection-device-types --region <aws-region>Example command output:........                },        {            "VpnConnectionDeviceTypeId": "7125681a",            "Vendor": "Fortinet",                   "Platform": "Fortigate 40+ Series",            "Software": "FortiOS 6.4.4+ (GUI)"        },        {                   "VpnConnectionDeviceTypeId": "9005b6c1",            "Vendor": "Generic",            "Platform": "Generic",                   "Software": "Vendor Agnostic"        },        {            "VpnConnectionDeviceTypeId": "670add1b",                   "Vendor": "H3C",            "Platform": "MSR800",            "Software": "Version 5.20"               },        {.......2.    Return the example configuration files you want by running the following get-vpn-connection-device-sample-configuration command:aws ec2 get-vpn-connection-device-sample-configuration --vpn-connection-id <vpn-id> --vpn-connection-device-type-id <device-type-id> --internet-key-exchange-version <ike-version> --region <aws-region> --output textImportant: Replace --vpn-connection-id with your VPN connection ID.Replace --internet-key-exchange-version with your internet key exchange version.Replace --vpn-connection-device-type-idwith the the Vendor:Platform:Software version from the previous command output.Related informationWhat do I do if I can't find the device specific VPN configuration file for my vendor?Follow"


Question: How can I enable Elastic IP addresses on my AWS Transfer Family SFTP-enabled server endpoint?

I want to make my AWS Transfer Family SFTP-enabled server accessible using Elastic IP addresses.

Answer: "I want to make my AWS Transfer Family SFTP-enabled server accessible using Elastic IP addresses.ResolutionTo make your AWS Transfer Family SFTP-enabled server accessible using Elastic IP addresses, create an internet-facing endpoint for your server.However, if you must change the listener port to a port other than port 22 (for migration), then see How can I enable Elastic IP addresses on my AWS Transfer Family SFTP-enabled server endpoint with a custom listener port?Related informationLift and shift migration of SFTP servers to AWSFollow"


Question: How can I use Amazon EMR to process data?

I want to use Amazon EMR to process data.

Answer: "I want to use Amazon EMR to process data.ResolutionAmazon EMR processes data using Amazon Elastic Compute Cloud (Amazon EC2) instances and open-source applications such as Apache Spark, HBase, Presto, and Flink.To launch your first EMR cluster, follow the video tutorial in the article, or see Tutorial: Getting started with Amazon EMR.Related informationOverview of Amazon EMROverview of Amazon EMR architectureFollow"


Question: How can I get my Amazon SQS subscription to successfully receive a notification from my Amazon SNS topic?

My Amazon Simple Queue Service (Amazon SQS) subscription won't receive a notification from my Amazon Simple Notification Service (Amazon SNS) topic.

Answer: "My Amazon Simple Queue Service (Amazon SQS) subscription won't receive a notification from my Amazon Simple Notification Service (Amazon SNS) topic.Short descriptionBefore you get started, configure Amazon CloudWatch delivery status logging for your SNS topic. For more information, see Monitoring Amazon SNS topics using CloudWatch.Then, try the following troubleshooting steps.ResolutionConfigure your SQS queue's access policy to allow Amazon SNS to send messagesTo view the access policy of your SQS queue, configure your access policy.If your SQS queue's access policy doesn't include the "sqs:SendMessage" action for your SNS topic, then update your policy with the correct permissions. The permissions must allow Amazon SNS to send messages to the SQS queue.Configure your AWS KMS key policy to work with server-side encryption on your SQS queueIf server-side encryption is enabled on your SQS queue, you must do the following:1.    Enable AWS KMS key status.2.    Verify that your SQS queue is using a customer managed key. The KMS key must have an AWS Key Management Service (AWS KMS) key policy that grants Amazon SNS the correct permissions.To allow the SNS event source to perform kms:GenerateDataKey and kms:Decrypt API actions, add the following statement to the KMS key policy:{    "Sid": "Allow Amazon SNS to use this key",    "Effect": "Allow",    "Principal": {        "Service": "sns.amazonaws.com"       },    "Action": [        "kms:Decrypt",        "kms:GenerateDataKey*"    ],    "Resource": "*"}If the KMS key policy isn't configured, then the Amazon SNS message delivery status logs show the following KMS.AccessDeniedException error:{    "notification": {        "messageMD5Sum": "1234567890abcdefghijklmnopqrstu0",        "messageId": "abcdef01-gh23-4i5j-678k-90l23m45nopq",           "topicArn": "arn:aws:sns:us-east-1:111111111111:sns",        "timestamp": "2021-06-17 17:08:10.299"    },    "delivery": {        "deliveryId": "12a3b4c5-6789-0de1-fgh2-ij34k56lmn78",        "destination": "arn:aws:sqs:us-east-1:111111111111:sns-sqs",        "providerResponse": "{\"ErrorCode\":\"KMS.AccessDeniedException\",\"ErrorMessage\":\"null    (Service: AWSKMS; Status Code: 400; Error Code: AccessDeniedException; Request ID: 12a345b6-7c89-0d1e-2f34-5gh67i8kl901; Proxy: null)\",\"sqsRequestId\":\"Unrecoverable\"}",        "dwellTimeMs": 60,           "attempts": 1,        "statusCode": 400    },    "status": "FAILURE"} Note: For more information, see Why aren't messages that I publish to my Amazon SNS topic getting delivered to my subscribed Amazon SQS queue that has server-side encryption activated?Confirm that your subscribed SQS queue's filter policy matches the message sent from the SNS topicReview the NumberOfNotificationsFilteredOut metric in your CloudWatch metrics for Amazon SNS.The Publish requests made by the AWS Identity and Access Management (IAM) entity that's invoking your function can appear in the NumberOfNotificationsFilteredOut metric. In this scenario, check the SNS topic subscription filter policy of your SQS queue:1.    Open the Amazon SNS console.2.    On the navigation pane, choose Subscriptions.3.    Select your subscription, and then choose Edit.4.    Expand the Subscription filter policy section.5.    In the subscription filter policy, confirm that the Publish request message attributes match the attributes required by the filter policy. If the attributes don't match, then update your Publish request message attributes to match the attributes required by the filter policy.Note: For more information, see Amazon SNS subscription filter policies.6.    Choose Save changes.Troubleshoot raw message delivery issuesIf you enabled raw message delivery for your SQS queue subscription, then verify that you're sending no more than 10 message attributes in the published notification.Amazon SNS maps the message attributes for raw delivery enabled messages to SQS message attributes. If you use more than 10 message attributes, then the notification delivery fails and your delivery status logs show the following error log:{    "notification": {        "messageMD5Sum": "5c10d6c5d7f246fc3fb85334b4ed55ca",        "messageId": "50f51b06-ee71-56fc-b657-424391902ee7",           "topicArn": "arn:aws:sns:us-east-1:111111111111:sns",        "timestamp": "2021-06-17 16:51:45.468"    },    "delivery": {        "deliveryId":    "36b3ee88-bc85-5587-b2af-b7cdc3644e07",            "destination": "arn:aws:sqs:us-east-1:111111111111:sns-sqs",        "providerResponse": "{\"ErrorCode\":\"InvalidParameterValue\",\"ErrorMessage\":\"Number of message    attributes [SENT DURING PUBLISH] exceeds the allowed maximum [10].\",\"sqsRequestId\":\"Unrecoverable\"}",        "dwellTimeMs": 44,        "attempts": 1,           "statusCode": 400    },    "status": "FAILURE"}Troubleshoot message deduplication with notification delivery for SNS FIFO topicsSNS FIFO topics order and deduplicate messages. If a notification for a deduplication ID is successfully sent to an SNS FIFO topic, then any message published with the same deduplication ID, within the five-minute deduplication interval, is accepted but not delivered.You can configure the deduplication ID in the Publish API operation. Or, the deduplication ID is computed by the FIFO topic based on the message body if content-based deduplication is enabled for the SNS FIFO topic.The SNS FIFO topic continues to track the message deduplication ID, even after the message is delivered to subscribed endpoints.For more information, see Message deduplication for FIFO topics.Follow"