Question: How can I troubleshoot replication lag or a backlog on my Linux Source Server for Application Migration Service?

I see lag or backlog in my Linux Source Server in when replicating data using AWS Application Migration Service.

Answer: "I see lag or backlog in my Linux Source Server in when replicating data using AWS Application Migration Service.Short descriptionThe following are factors that contribute to replication lag and backlog when replicating data from a source server to a target server:Network uplink speed and bandwidth availability: The network connection speed between the source server and the replication server might have significant impact on replication performance. Slow connections might prevent the replication process from completing. Also, limited bandwidth limits the amount of data that you can replicate in a given time.Changes in disk while replicating: During the replication process, the source server might continue to write new data to its disks. If there's a large spike in the amount of new data that the source server is writing, then data accumulates and creates a significant backlog. The AWS Replication Agent must send this backlog with the initial sync. The larger the backlog, the longer it takes to complete the data replication.I/O speed of the storage disks: During the replication process, the AWS Replication Agent reads storage blocks of disks and transmits data to the replication server. However, high read latency on the source server disks might impact the speed and efficiency of the data replication. Slow disks cause delays, and fast disks improve replication speed.Load on source server: Resource contention on the source server might lead to high CPU utilization, memory consumption, I/O wait, or other resource constraints. For example, high CPU utilization might cause replication bottlenecks. This is because the system struggles to allocate CPU resources between the AWS Replication Agent and other processes. Similarly, high memory consumption might cause the system to swap memory pages to disk. This results in increased I/O wait and a slowdown in the replication process.Under-provisioned replication resources: Staging Amazon Elastic Block Store (Amazon EBS) volumes with lower throughput and IOPS might cause high read and write latency, high queue length. All of these issues impact replication performance. Also, a replication server instance type with low network throughput and Amazon EBS bandwidth leads to replication performance issues.ResolutionTo determine the underlying reason for the lag, first perform checks on the source server. Then, perform checks on the staging area.Source server checksVerify that the source server is booted and runningMake sure that the Source Server for the migration is booted and running.Verify that the source server can establish an SSL connection with the regional Application Migration Service API endpoint and the replication serverMake sure that SSL certificates aren't intercepted and changed at any point between the source server and the Application Migration Service API endpoint. And, make sure that the SSL certificates aren't intercepted and changed between the source server and the replication server. To do this, run the following command:# echo -n | openssl s_client -connect mgn.<region>.amazonaws.com:443# echo -n | openssl s_client -connect <replication server IP>:1500Note: Use the command listed in the following Verify active TCP connections section to find the replication server's IP address.Verify that all AWS Replication Agent processes are runningRun the following command to list the running AWS Replication Agent services:# ps -u aws-replicationThe following output shows the AWS Replication Agent processes that must be running: PID  TTY TIME    CMD 30878 ? 00:00:00 update_onprem_v 30879 ? 00:00:00 run_linux_migra 30880 ? 00:00:00 tailer 30881 ? 00:04:45 java 30902 ? 00:00:01 tailer 30904 ? 00:00:00 run_linux_migra 30905 ? 00:00:10 update_onprem_v 31023 ? 00:00:00 tailVerify active TCP connectionsRun the following command to verify that there are five active TCP connections established with the replication server on TCP Port 1500.# sudo netstat -anp | awk '$5 ~ /:1500$/ {print}'Check the command output for the active connections:tcp6       0      0 172.31.1.39:54814       172.31.0.82:1500        ESTABLISHED 30881/java          tcp6       0      0 172.31.1.39:54828       172.31.0.82:1500        ESTABLISHED 30881/java          tcp6       0      0 172.31.1.39:54832       172.31.0.82:1500        ESTABLISHED 30881/java          tcp6       0      0 172.31.1.39:54812       172.31.0.82:1500        ESTABLISHED 30881/java          tcp6       0      0 172.31.1.39:54800       172.31.0.82:1500        ESTABLISHED 30881/javaCheck CPU utilization on the CPU core where the AWS Replication Agent is runningThe AWS Replication Agent is a single-threaded process that operates on one CPU core at a time. If CPU utilization is high on the core where the AWS Replication Agent is running, then data replication slows.1.    Run the following commands and then review the output to determine the following:The process ID of the AWS Replication Agent.The CPU core (indicated by psr) that it's running on.# ps --pid $(pidof /var/lib/aws-replication-agent/jre/bin/java) -o psr,pid,comm# mpstat -P <psr column value> 32.    Then, check the CPU utilization of the identified CPU core.Check disk performance on the source serverIf there's low read throughput (rMB/s) on source disks, then less data is read and replicated. Make a note of any increase in the IO depth (avgqu-sz) and I/O wait (await) metrics. You can use sar or iostat tools to measure the disk read throughput:# iostat -myx 3# sar -dp 2Check the source server for a spike in write operationsA spike of write operations in the source server might cause replication lag growth. This growth continues until the AWS Replication Agent flushes all the written data to the replication server. Run the iostat test periodically to determine what the I/O load is as the workload changes. If the write throughput (wMB/s) exceeds the available network throughput, then you see replication lag.Note: To calculate the required bandwidth from source server to replication server, see Calculating the required bandwidth for TCP Port 1500.Check replication speed and available bandwidth from the source server to the staging area subnet1.    In your target AWS Region, launch a test Amazon Elastic Compute Cloud (Amazon EC2) instance using the publish AMI CE-ssl-speedtest. The EC2 instance must be the same instance type as the replication server.2.    Select the same subnet as the subnet used in the replication settings of your source server.3.    Make sure that the security group allows TCP Port 1500 inbound access.4.    On the source server, configure the SpeedTest CLI as shown in the following example:# cd /tmp# git clone https://github.com/librespeed/speedtest-cli.git# cd speedtest-cli/# ls -l# ./build.sh# cat << EOF >> ./servers.json[  {    "id": 1,    "name": "PHP Backend",    "server": "https://<test server private IP>:1500/speedtest/",    "dlURL": "/garbage.php",    "ulURL": "/empty.php",    "pingURL": "/empty.php"  } ]EOFNote: In the preceding example, make sure to replace the test server's IP address. If you're using the test server's public IP for a speed test, include "getIpURL": "/getIP.php" after the "pingURL" line.5.    Run the LibreSpeed CLI as shown in the following example to test the replication speed:# ./out/librespeed-cli-linux-amd64 —local-json ./servers.json —server 1 —no-icmp —skip-cert-verify —simplePing: 11.00 ms Jitter: 0.00 msDownload rate: 503.84 MbpsUpload rate: 493.56 MbpsCheck for a source server that was shut down ungracefullyIf a source server is shut down ungracefully, then the AWS Replication Agent rescans all of the disks after the server reboots. The AWS Replication Agent rereads the disks, and the lag continuously grows until rescanning completes. For more information, see Which Windows and Linux OSs support no-rescan upon reboot?Check for a kernel upgradeIf the kernel is upgraded on the source server and the server is rebooted, then the AWS Replication Agent fails to run. The running kernel version matches the kernel version that the AWS Replication Agent driver was compiled for during the agent installation.Run the following commands to verify that the running kernel version matches the kernel version that the AWS Replication Agent driver was compiled for:$ uname -r$ modinfo -F vermagic /var/lib/aws-replication-agent/aws-replication-driver.koNote: vermagic is used to verify that which kernel version the kernel driver is compiled.Verify that TCP Port 1500 isn't blocked outboundMake sure that TCP Port 1500 isn't blocked outbound from the source server to the replication server.Review the MGN Agent logsInspect the MGN Agent logs for any connectivity problems with the replication server on TCP Port 1500. Also, check for replication irregularities that indicate frequent connection loss. After identifying these issues, review the network topology to investigate further.Verify that intermediate devices don't have a lower MTUConfirm that none of the intermediate devices in the replication path have a lower MTU. A lower MTU reduces the replication speed and cause delays in the process. It's a best practice to maintain a consistent MTU size throughout the replication path. If a device in the path has a lower MTU, then update or replace it with a higher MTU device.Note: If you're replicating over the public Internet, then make sure that the MTU is 1500. 1500 is the largest that internet gateway, peering, and VPN supports. Jumbo frames only work within Amazon Virtual Private Cloud (Amazon VPC) or AWS Direct Connect and has its own limitations. For more information, see the following:MTUJumbo FramesVerify that network bandwidth throttling is turned off in the replication settings on the source serverBandwidth throttling must be turned off in the replication settings of the source server.Turning on bandwidth throttling in the source server throttles the data transfer rate of the AWS Replication Agent. This might result in constant or stagnant lag growth if there is backlog on the source server. To maintain constant and limited bandwidth for data transfer, turn on network bandwidth throttling.To check for bandwidth throttling, complete the following steps:1.    Open the Application Migration Service console.2.    Choose Source servers, and then select the source server.3.    Choose the Replication settings tab.3.    If Throttle network bandwidth is turned on, then make sure that the throttled value is equal to or greater than the required bandwidth for data replication. For more information, see the note in the preceding section, Check the source server for a spike in write operations.Staging area resource checksVerify that TCP Port 1500 isn't blocked inboundMake sure the TCP Port 1500 isn't blocked inbound in the replication server's security groups.Note: You must complete the following steps in the Amazon Elastic Compute Cloud (Amazon EC2) console.1.    Open the Amazon EC2 console.2.    Select the security group that's attached to the replicator instance.3.    Verify that inbound TCP Port 1500 is allowed on the attached security group.Check the NetworkIn CloudWatch metricIf the NetworkIn Amazon CloudWatch metric for the replication server nears the bandwidth limit, throttling might occur. Throttling results in slower replication speed and increased lag. Consider upgrading to a larger instance type that can handle the required bandwidth.Check the aggregated throughput and IOPS of the replication server's EBS volumesReplication server performance might be throttled if the Amazon Elastic Block Store (Amazon EBS) volumes' aggregated throughput and IOPS exceed limits. If throttling occurs, change to a replication server instance type that accommodates your replication needs and sustain performance without throttling. It's a best practice to use a current generation EBS-optimized instance type for replication servers. On instances without support for EBS-optimized throughput, network traffic contends with traffic between your instance and your EBS volumes. On EBS-optimized instances, the two types of traffic are kept separate. Monitor replication server network and EBS CloudWatch metrics. For more information, see the following:Instance metricsAmazon EBS metrics for Nitro-based instancesMonitor metrics for all replication EBS volumesLag and backlog accumulate when the replication server's volume write speed can't match the rate of change on the source server. To avoid replication lag, use a faster volume type with higher IOPS and bandwidth. For optimal performance EBS volume performance, it's a best practice to monitor the CloudWatch metrics for every replication EBS volume.Check for EBS volumes created from a snapshotReplication server's that have EBS volumes created from a snapshot, might have increased I/O operations latency the first time each block is accessed. This latency might cause lag growth or stagnation until the rescanning process is complete. For more information, see Be aware of the performance penalty when initializing volumes from snapshots.Verify the snapshot quota in the target RegionMake sure that your AWS account hasn't reached snapshot quota limits in the AWS Region where you're replicating source servers. Use the following AWS Command Line Interface (AWS CLI) commands to verify if you've reached the snapshot quota in the Region. In the following example, replace region with your target AWS Region:# aws service-quotas get-service-quota --service-code ebs --quota-code L-309BACF6 --region region --query "Quota.Value"# aws ec2 describe-snapshots --owner-ids self --region region --query "length(Snapshots)"Note: If you receive errors when running the AWS CLI commands, make sure that you're using the most recent version of the AWS CLI.Related informationIdentification of replication bottlenecks when using AWS Application Migration ServiceFollow"


Question: How can I reset the administrator password on an EC2 Windows instance?

I want to reset the administrator password on my Amazon Elastic Compute Cloud (Amazon EC2) Windows instance.

Answer: "I want to reset the administrator password on my Amazon Elastic Compute Cloud (Amazon EC2) Windows instance.ResolutionYou can use AWS Systems Manager or EC2Rescue to reset the administrator password on your EC2 Windows instance.Systems Manager Run Command AWSSupport-RunEC2RescueForWindowsTool (online method)Prerequisites:You must configure Systems Manager for your AWS account, and then install the Systems Manager agent on the instance. For more information, see Setting up AWS Systems Manager.The instance must have internet access (for Systems Manager) using a public IP address or NAT.-or-The instance must use an Amazon Virtual Private Cloud (Amazon VPC) endpoint configured for Systems Manager.For more information, see AWS PrivateLink concepts.To reset the administrator password with Systems Manager using the Run Command, follow these steps:1.    Attach the following policy to the IAM role associated with the instance to write the encrypted password to Parameter Store:{   "Version": "2012-10-17",   "Statement": [     {       "Effect": "Allow",       "Action": [       "ssm:PutParameter"       ],       "Resource": [         "arn:aws:ssm:*:*:parameter/EC2Rescue/Passwords/i-*"         ]     }   ] }2.    Open the AWS Systems Manager console, and then choose Run Command from the navigation pane.3.    Choose Run a Command.4.    For Command document, choose AWSSupport-RunEC2RescueForWindowsTool.5.    For Command parameters, verify that Command is set to ResetAccess.6.    For Targets, choose Choose instances manually, and then select your instance.7.    Choose Run.8.    In the Targets and outputs section, select the Instance ID for your instance.9.    Choose View output for instructions on how to retrieve the new password.10.    After you regain access to your instance, it’s a best practice to rotate the password and then delete the parameter from Parameter Store.For more information, see Use EC2Rescue for Windows Server with Systems Manager Run Command.Reset passwords on managed nodes (online method)You can reset the password for any user on a managed node of an Amazon EC2 instance. For instructions, see Reset a password on a managed node.Be sure to confirm you meet all the prerequisites before using this method.Systems Manager Automation AWSSupport-ResetAccess (offline method)Warning: Before you run the automation, be aware of the following:If you're not using an Elastic IP address, then the public IP address is released when you stop the instance.If this instance has an instance store volume, then any data on it is lost when the instance stops.If the instance shutdown behavior is set to Terminate, then the instance terminates when it stops.If the instance is part of an Auto Scaling group, first detach the instance from the Auto Scaling Group. Then, after you stop and start the instance, attach the instance back to the Auto Scaling group.For more information, see Stop and start your instance.AWSSupport-ResetAccess is a Systems Manager Automation document that automates EC2Rescue offline password reset using AWS CloudFormation and AWS Lambda functions. The automation document:Creates an instance to assist with recovery in your Availability Zone.Attaches and detaches EBS volumes.Runs the EC2Rescue utility.Creates an Amazon VPC for EC2Rescue isolated from your environment.Creates a backup AMI of the instance.You can use the AWSSupport-ResetAccess document if:You lost your EC2 key pair. Now you want to create a password-enabled AMI from your EC2 instance to launch a new instance with an existing key pair.You lost your local administrator password. Now you want to generate a new password that you can decrypt with the current EC2 key pair.Important: You can't use the AWSSupport-ResetAccess document with encrypted root EBS volumes.1.    Open the AWS Systems Manager console, and then choose Automation from the navigation pane.2.    Choose Execute automation.3.    For Automation document, choose AWSSupport-ResetAccess, and then choose Next.4.    For Input parameters, enter the InstanceID of your EC2 instance.5.    Choose Execute.6.    Wait until the state changes to Success. This can take up to 25 minutes.Note: On the Execution detail page, view Executed steps to monitor the progress. Expand Outputs to view the output of the automation. To return to this page, open the AWS Systems Manager console, and then choose Automation from the navigation pane. Select the running automation, and then choose View details.7.    Use your existing key pair to decode the newly generated password from the EC2 console. For more information, see How do I retrieve my Windows administrator password after launching an instance?Systems Manager Run Command (online method)Prerequisites:You must configure Systems Manager for your AWS account, and then install the Systems Manager agent on the instance. For more information, see Setting up AWS Systems Manager.The instance must have internet access (for Systems Manager) using a public IP address or NAT.-or-The instance must use an Amazon Virtual Private Cloud (Amazon VPC) endpoint configured for Systems Manager.For more information, see AWS PrivateLink concepts.1.    Open the AWS IAM console.2.    Choose Roles, Create new role.3.    Choose EC2, and then choose Select.4.    Under Policy Name, check AmazonSSMManagedInstanceCore, and then enter a Role name.5.    Choose Create Role.6.    Open the Amazon EC2 console, and choose the appropriate Region.7.    Select the affected instance, and then choose Actions, Security, Modify IAM role.8.    Select the IAM role you just created, and then select Save.Note: After attaching the IAM role to the instance with the proper IAM policy, wait for about 5 minutes. You can see your instance in Managed Instances in the AWS Systems Manager console. If the instance doesn't appear under Managed Instances, try rebooting the instance. If the instance still doesn't appear, see Why is my EC2 instance not displaying as a managed node or showing a "Connection lost" status in Systems Manager?9.    After the instance appears in Managed Instances, choose Run Command in the AWS Systems Manager console.10.    Choose Run a command.11.    For Command document, choose AWS-RunPowerShellScript.12.    For Command parameters, copy and paste the following command. Replace Password@123 with your password:net user Administrator Password@123Important: The command records details of your user name and password in AWS Systems Manager Agent (SSM Agent) logs, which can cause unauthorized access to the instance. After you regain access to your instance, it’s a best practice to change your password.13.    For Targets, choose Choose instances manually, and then select the instance that needs the password reset.14.    Choose Run.Note: Leave all the settings at default.Following the successful completion of the run command, you can now log in to the instance using the local administrator password used in step 12. It's a best practice to change your password after using this method.If you lost your EC2 key pair1.    Stop your instance.Warning: Before you stop an instance, be aware of the following:If you're not using an Elastic IP address, then the public IP address releases when you stop the instance.If this instance has an instance store volume, then any data on it is lost when the instance stops.If the instance shutdown behavior is set to Terminate, then the instance terminates when it stops.If the instance is part of an Auto Scaling group, then first detach the instance from the Auto Scaling Group. Then, after you stop and start the instance, attach the instance back to the Auto Scaling group.For more information, see Stop and start your instance.2.    Open the Amazon EC2 console, and then choose AMIs.3.    Search for your instance ID.4.    Select the AMI named AWSSupport-EC2Rescue-Post-Script-Backup-i-xxxxxxxxx_Date, and then choose Launch.5.    Follow the Launch Wizard to specify the configuration of your instance, and then select a key pair that you own.6.    Verify that you can connect to the new instance and that your applications are working as expected before terminating the other instance.EC2Rescue (offline or online method)To regenerate the administrator password at next boot, turn on EC2SetPassword using EC2Rescue:1.    Choose Diagnose and Rescue. The EC2Config section shows the current Ec2SetPassword setting. Choose Next.2.    In Detect possible issues, select the Ec2SetPassword check box, and then choose Next.For more information, see How can I use EC2Rescue to troubleshoot issues with my Amazon EC2 Windows instance?Related informationIdentity and access management for Amazon EC2Troubleshoot EC2 Windows instancesUse EC2Rescue for Windows ServerRun the EC2Rescue tool on unreachable instancesAWS Systems ManagerFollow"


Question: Why am I unable to access my PCoIP-based WorkSpace using the WorkSpaces client?

I tried to log in to my PCoIP WorkSpace using the Amazon WorkSpaces client. I received an error when attempting to connect to my desktop. What issues cause these error messages?

Answer: "I tried to log in to my PCoIP WorkSpace using the Amazon WorkSpaces client. I received an error when attempting to connect to my desktop. What issues cause these error messages?Short descriptionThe WorkSpaces client depends on special services and network settings. When the client fails to load the WorkSpace, it's typically because a service or setting is incorrectly configured or unavailable.ResolutionThe following information describes common errors, the cause of these errors, and troubleshooting guidance to resolve the errors.After authentication, the WorkSpaces client is stuck on a WorkSpaces launch screen. After a few seconds, the following error displays: "Unknown error Occurred. We couldn't launch your WorkSpace. Please try again. If you need help, contact your administrator."This error typically indicates that the WorkSpaces client can authenticate over port 443, but can’t establish a connection over TCP port 4172. This might happen when network prerequisites aren’t met. Issues on the client side might cause the network check for the client to fail. Choose the icon in the top-right corner to see which health checks are failing.Note: A client-side firewall or proxy might cause a health check failure by preventing access over TCP port 4172. If this health check fails, check your local firewall settings.If the network checks are passing on the client, then it indicates a problem with the WorkSpace network configuration. For example, a Windows Firewall rule that's applied locally or through a group policy object (GPO), or an antivirus check might block TCP port 4172 on the management interface.  Connect to the WorkSpace using the Remote Desktop Protocol (RDP) client to verify that the WorkSpace meets the same port requirements.After authentication, the WorkSpaces client displays a "Launching Session" screen. The client window expands and displays a white screen before displaying a "Disconnected" message. No other error message appears.This error typically indicates that the WorkSpaces client can authenticate over port 443, but can’t establish a streaming connection over UDP port 4172. This might happen when network prerequisites aren’t met. Issues on the client side might cause the network check of the client to fail. Choose the icon in the top-right corner to see which health checks are failing.Note: A client-side firewall or proxy might cause a health check failure by preventing access over UDP port 4172. If this health check fails, check your local firewall settings.If the network checks are passing on the client, then it indicates a problem with the network configuration on the WorkSpace. For example, a Windows Firewall rule that's applied locally or through a group policy object (GPO), or an antivirus check might block UDP port 4172 on the management interface. Connect to the WorkSpace using an RDP client to verify that the WorkSpace meets the same port requirements.After authentication, the WorkSpaces client displays a "Launching Session" screen, but after a few seconds, the client displays one of the following error messages.Unable to connect. Your WorkSpace is not reachable at the moment. You can try and reconnect anytime.Unable to connect. We couldn't launch your WorkSpace. Please try again. If you need help, contact your administrator.Unable to login. We couldn't launch your WorkSpace. Please try again. If you need help, contact your administrator.These errors typically indicate that the SkyLightWorkSpacesConfigService or the PCoIP Standard Agent for Windows services aren’t responding to health checks. If either of these services aren't running, then the status of the WorkSpace on the WorkSpaces console typically displays Unhealthy. Usually, rebooting the WorkSpace from the WorkSpaces console or the WorkSpaces client resolves the issue.However, sometimes rebooting the WorkSpace doesn't help.To resolve the issue, check the status of the WorkSpace on the WorkSpaces console. If it shows Rebooting or Starting for a long time and then changes to Unhealthy, then verify the following settings for the SkyLightWorkSpacesConfigService and PCoIP Standard Agent for Windows services:They're running.They're set to start automatically.They can communicate over the management interface (eth0).They aren't blocked by any third-party antivirus software.The Windows Firewall or group policy settings aren't blocking communication on the management interface.To verify that the SkyLightWorkSpacesConfigService and PCoIP Standard Agent for Windows services meet the preceding requirements, follow these steps:1.    Connect to the WorkSpace by using RDP.2.    Open Windows PowerShell as an administrator by choosing Run as administrator.3.    Run the following command to enable all network adapters for the WorkSpace:Get-NetAdapter | Where status -ne Up | Enable-NetAdapter4.    Run the following command:Get-Service -Name SkyLightWorkspaceConfigService, PCoIPAgent | Select-Object -Property Name, DisplayName, Status, Starttype5.    In the output of the preceding command, usually the Status displays Running and StartType displays Automatic. However, if the status displays Stopped, then run the following commands to start the service:Get-Service -Name SkyLightWorkspaceConfigService | Start-ServiceGet-Service -Name PCoIPAgent | Start-Service6.    If the Status displays Stopped and StartType displays Disabled or Manual, run the following commands to change StartType to Automatic first. Then, start the service:Get-Service -Name SkyLightWorkspaceConfigService | Set-Service -StartupType AutomaticGet-Service -Name SkyLightWorkspaceConfigService | Start-ServiceGet-Service -Name PCoIPAgent | Set-Service -StartupType AutomaticGet-Service -Name PCoIPAgent | Start-ServiceFor more information about troubleshooting unhealthy WorkSpaces, see How do I troubleshoot a Windows WorkSpace that's marked as unhealthy?Unable to register. This device is not authorized to access the WorkSpace. Please contact your administrator for assistance.There are few reasons for this error. Any combination of one, two, or all the causes might result in this error:IP access control groups are configured on your WorkSpace directory, but the client IP address isn't on an allow list.Trusted device-based access is turned on in the directory, and the certificate is missing on the client device, isn't valid, or isn't meeting security requirements.Device access is turned off in the WorkSpaces directory.Check the settings in your directory. If the IP access control group is turned on, then confirm that the public IP address the user is connecting from allows access to the WorkSpace.If the trusted device setting is turned on under Access Control Options and displays Valid, then make sure that you have the correct leaf, intermediate (optional), and root certificates installed on the client machine.Make sure that the client device that you're accessing the WorkSpace from is allowed under Access Control Options. By default, WorkSpaces Web Access and Linux clients are turned off.Related informationTroubleshoot WorkSpaces issuesFollow"


Question: How do I turn on Object Lock for an existing Amazon S3 bucket?

I want to turn on Object Lock for an existing Amazon Simple Storage Service (Amazon S3) bucket.

Answer: "I want to turn on Object Lock for an existing Amazon Simple Storage Service (Amazon S3) bucket.ResolutionNote: If you receive errors when running AWS CLI commands, make sure that you're using the most recent version of the AWS CLI.You need an Object Lock token value to turn on Object Lock for an existing S3 bucket. To get this value, contact AWS Support.Note that you can request for an Object Lock token value to be generated only for version-enabled buckets.After you get the token from AWS Support, run the following AWS Command Line Interface (AWS CLI) command. You can use the latest version of AWS CLI on a local machine or AWS CloudShell to run this command:aws s3api put-object-lock-configuration --bucket bucketname --token token-value --object-lock-configuration "ObjectLockEnabled=Enabled,Rule={DefaultRetention={Mode=string,Days=integer,Years=integer}}"For more information, see put-object-lock-configuration.Be sure to do the following:Replace bucketname with the name of the bucket.Replace token-value with the Object Lock token value.You can set Mode to GOVERNANCE or COMPLIANCE and specify the duration in either Days or Years. Don't use both Days and Years in the command. Otherwise, you get the Malformed XML error.This command produces no output.To verify if Object Lock is turned on for your S3 bucket, view the default object lock settings using the Amazon S3 console.You can also use the GetObjectLockConfiguration API.aws s3api get-object-lock-configuration --bucket bucketnameAlso, see Viewing the lock information for an object.Important: After you configure the S3 Object Lock successfully, you can't turn it off. Also, you can't suspend versioning on the bucket.Related informationUsing S3 Object LockFollow"


Question: How can I troubleshoot issues when granting public read access to an Amazon S3 object using a bucket policy or an object ACL?

"I'm trying to grant public read access to the objects in my Amazon Simple Storage Service (Amazon S3) bucket using a bucket policy or an object access control list (ACL). However, I get Insufficient Permissions or Access Denied errors."

Answer: "I'm trying to grant public read access to the objects in my Amazon Simple Storage Service (Amazon S3) bucket using a bucket policy or an object access control list (ACL). However, I get Insufficient Permissions or Access Denied errors.Short descriptionSuppose that you're using the following bucket policy to grant public read access to the objects in your bucket:{    "Version": "2012-10-17",    "Statement": [        {            "Sid": "PublicReadGetObject",            "Effect": "Allow",            "Principal": "*",            "Action": [                "s3:GetObject"            ],            "Resource": [                "arn:aws:s3:::example-bucket/*"            ]        }    ]}You might get the Insufficient Permissions or Access Denied errors because of the following reasons:You don't have the s3:PutBucketPolicy permission to update or create a bucket policy for your Amazon S3 bucket.You don't have the s3:PutObjectAcl permission to modify the object's ACL.The S3 bucket policy or the object's ACL conflicts with your S3 Block Public Access settings.ResolutionGrant the required permissionsBe sure that AWS identity and Access Management (IAM) user or role that you use has the following permissions:s3:PutBucketPolicy to create or update the bucket policy for your S3 buckets3:PutObjectAcl to update an object's ACL for granting public read accessUpdate the Block Public Access SettingsBy default, all Amazon S3 resources, such as buckets, objects, and related subresources, are private and don't allow public access. The Block Public Access settings for access points, buckets, and accounts help you to manage public access to Amazon S3 resources. These settings override the S3 bucket policies and object ACLs so that you can limit public access to these resources. When the bucket policy or object ACL that you configured conflicts with the Block Public Access setting, you can't create a bucket policy to grant public read access. S3 also denies permissions to modify the bucket policy or object ACLs to grant public read access.Amazon S3 Block Public Access provides four settings to block public access to buckets and objects. These settings are independent and can be used in any combination.BlockPublicAcls - Block public access that's granted using new ACLs: Amazon S3 blocks public access permissions that you apply to newly added buckets or objects. S3 also denies the creation of new public access ACLs for existing buckets and objects. This setting doesn't change any existing permissions that allow public access to S3 resources that use ACLs.IgnorePublicAcls - Block public access that's granted using any ACL: Amazon S3 ignores all ACLs that grant public access to buckets and objects.BlockPublicPolicy - Block public access that's granted using a new public bucket or access point policies: Amazon S3 blocks the use of new buckets and access point policies that grant public access to buckets and objects. This setting doesn't change any existing policies that allow public access to S3 resources.RestrictPublicBuckets - Block public and cross-account access that's granted using any public bucket or access point policies: Amazon S3 ignores public and cross-account access for buckets or access points with policies that grant public access to buckets and objects.For more information, see Amazon S3 Block Public Access - Another layer of protection for your accounts and buckets.Be sure to update the S3 Block Public Access settings based on your use case. Note:If you're granting public read access to objects using ACLs, then turn off the following Block Public Access settings:BlockPublicAcls at both bucket level and account levelIgnorePublicAcls at both bucket level and account levelIf you're granting public read access to objects using an S3 bucket policy, then turn off the following Block Public Access settings:BlockPublicPolicy at both bucket level and account levelRestrictPublicBuckets at both bucket level and account levelYou can't use bucket ACLs or object ACLs to grant public read access for buckets that have the S3 Object Ownership set to Bucket Owner Enforced. In this case, you must use policies to grant access to your bucket and the objects in the bucket. Requests to set or update ACLs fail, and you get the AccessControlListNotSupported error message. Request to read ACLs are still supported.If you turned on Block Public Access settings for all S3 buckets in your account, then you see the message Bucket and objects not public. For more information, see Configuring block public access settings for your account.Important: When you grant public read access to the objects, anyone on the internet can access these objects. If this isn't what you want, then make sure that your S3 bucket isn't publicly accessible. For more information, see Amazon S3 security best practices.Related informationHow can I grant public read access to some objects in my Amazon S3 bucket?Follow"


Question: How do I perform a backup of my Amazon RDS for MySQL DB instance?

I'm trying to perform a backup of my Amazon Relational Database Service (Amazon RDS) for MySQL DB instance. How can I do this?

Answer: "I'm trying to perform a backup of my Amazon Relational Database Service (Amazon RDS) for MySQL DB instance. How can I do this?Short descriptionAmazon RDS for MySQL creates and saves automated backups of your DB instance during the backup window. A storage volume snapshot of your entire DB instance (and not just individual databases) is created. Amazon RDS then saves the automated backups of your DB instance according to the backup retention period that you specify. During the backup retention period, you can recover your database to any point in time.However, if your DB instance doesn't have automated backups enabled, you can enable this setting at any time. To enable automated backups, set the backup retention period to a positive nonzero value. When automated backups are enabled, your RDS instance and database is taken offline and a backup is immediately created. The outage occurs when you change the backup retention period from "0" to a nonzero value, or from a nonzero value to "0". This behavior applies to both Single-AZ and Multi-AZ DB instances.You can also use a cron job to schedule a backup of your Amazon RDS for MySQL instance using either the mysqldump or mysqlbinlog utility. Or, you can perform a manual backup using the AWS Command Line Interface (AWS CLI). The manual snapshots aren't subject to the backup retention period and will not expire.Note: If you receive errors when running an AWS CLI command, make sure that you’re using the most recent version of the AWS CLI.ResolutionEnabling automated backupsTo enable automated backups in Amazon RDS, perform the following steps:1.    Open the Amazon RDS console.2.    From the navigation pane, choose Databases.3.    Select the DB instance that you want to modify.4.    Choose Modify. The Modify DB instance page will appear.5.    For Backup retention period, choose a positive nonzero value (such as "3").6.    Choose Continue.7.    Choose Apply immediately.8.    On the confirmation page, choose Modify DB instance to save your changes and enable automated backups.Note: When you delete a DB instance, you can still retain automated backups. Retained automated backups include the following:System snapshots of a DB instanceTransaction logs from a DB instanceDB instance properties (such as allocated storage and DB instance class, which are required to restore the DB instance to an active instance)You can retain automated backups for Amazon RDS instances running on MySQL, MariaDB, PostgreSQL, Oracle, and Microsoft SQL Server engines. Or, you can use mysqlbinlog (for binlog files) or mysqldump (for logical backups) to back up files to an Amazon Elastic Compute Cloud (Amazon EC2) instance. Then, sync and upload your files to Amazon Simple Storage Service (Amazon S3).Note: On the read replica, only the Amazon RDS for MySQL or MariaDB read replica can enable backup retention.Backing up the Amazon RDS for MySQL DB instance on Amazon EC2To back up your Amazon RDS for MySQL instance on an Amazon EC2 instance, you can choose one of the following methods:Use mysqldump to copy the database and execute a cron job. The mysqldump utility creates a backup while copying the data from Amazon RDS for MySQL to your local client computer or Amazon EC2 instance. For more information, see mysqldump on the MySQL website.-or-Use mysqlbinlog to produce and stream binlog files to an Amazon EC2 instance. You can use mysqlbinlog to schedule a backup of your DB instance's binary log files to an Amazon S3 bucket. For more information, see How can I schedule Amazon RDS MySQL DB instance binlog files to be uploaded to Amazon S3?Follow"


Question: How do I set up a chat widget for my application that natively interacts with Amazon Connect and Amazon Connect Participant Service APIs?

I want to create a chat widget for an application that natively interacts with Amazon Connect and Amazon Connect Participant Service APIs. How do I set that up?

Answer: "I want to create a chat widget for an application that natively interacts with Amazon Connect and Amazon Connect Participant Service APIs. How do I set that up?ResolutionTo initiate customer chat contacts directly from your application using Amazon Connect and Amazon Connect Participant Service APIs, configure your application to do the following.Call the StartChatContact Amazon Connect API when a customer initiates a chat contactConfigure your application to call the StartChatContact Amazon Connect API when a customer initiates a chat contact. The API response returns a ParticipantToken value that's required to call the CreateParticipantConnection API in the next step.Important: The client that's making the API call must have AWS Identity and Access Management (IAM) permissions to perform the connect:StartChatContact action.To deploy the resources required to call the StartChatContact API from your application, you can use the following AWS CloudFormation template on GitHub: amazon-connect-chat-ui-examples. The template creates an Amazon API Gateway endpoint that invokes an AWS Lambda function that includes the required IAM permissions. The AWS Lambda function invokes the Amazon Connect StartChatContact API and returns the result from that call.Example StartChatContact API request (JavaScript)If you're using axios in your application, you can use the following JavaScript code to call the StartChatContact API:const startChatApi = "https://xxxxxxxxxx.execute-api.<region>.amazonaws.com/Prod"; // API endpoint you deployed with the CloudFormation template. ...axios.post(  startChatApi,  {    ParticipantDetails: {      DisplayName: "CUSTOMER" // This is going to be a display name of your customer during a chat contact    }  });Call the CreateParticipantConnection Amazon Connect Participant Service API and pass the ParticipantToken valueConfigure your application to call the CreateParticipantConnection Amazon Connect Participant Service API after a chat contact is initiated.Invoking the CreateParticipantConnection API returns a WebSocket URL and ConnectionToken. Clients must manually connect to the WebSocket URL and subscribe to the desired topic ("aws/chat") to create the chat participant's connection.Note: The Amazon Connect Participant Service APIs don't use Signature Version 4 authentication. For the X-Amz-Bearer request header value, you must use either the ParticipantToken or ConnectionToken value instead. The ParticipantToken value is used when calling the CreateParticipantConnection API only. Other Amazon Connect Participant Service APIs require you to pass the ConnectionToken value.Example CreateParticipantConnection API request (JavaScript)If you're using axios in your application, you can use the following JavaScript code to call the CreateParticipantConnection API:const participantServiceEndpoint = "https://participant.connect.<region>.amazonaws.com";// Replace <region> with the one that you are using. i.e. us-west-2. Endpoint list is available in https://docs.aws.amazon.com/general/latest/gr/connect_region.html...const requestHeaders = {  "X-Amz-Bearer": "ParticipantToken", // Replace "ParticipantToken" with the one you obtained from the response of StartChatContact API  "Content-type": "application/json"};const requestBody = {  "Type": ["WEBSOCKET", "CONNECTION_CREDENTIALS"]};axios.post(participantServiceEndpoint + "/participant/connection", requestBody, {  headers: requestHeaders});Create a WebSocket connection using the returned WebSocket URL and subscribe the application to the "aws/chat" topicAfter invoking the CreateParticipantConnection API, the client must manually connect to the returned WebSocket URL and subscribe to the "aws/chat" topic.For more information, see CreateParticipantConnection in the Amazon Connect Participant Service API Reference.Example JavaScript code that creates a WebSocket connection and subscribes a client to the "aws/chat" topicconst ws = new WebSocket(websocketUrl); // Here, you use the websocket URL that you obtained from the response of CreateParticipantConnection APIconst initialMessage = {  topic: "aws/subscribe",  content: {    topics: ["aws/chat"]  }};ws.addEventListener("open", () => {  ws.send(JSON.stringify(initialMessage))});Send chat messages or events by calling Amazon Connect Participant Service APIsNote: You can't send messages or events directly through the WebSocket connection. You must use one of the Amazon Connect Participant Service APIs instead.To send chat messages, call the SendMessage Amazon Connect Participant Service API.-or-To send events, call the SendEvent Amazon Connect Participant Service API.Important: For the X-Amz-Bearer request header, make sure that you use the ConnectionToken value that's returned by the CreateParticipantConnection API.Example SendMessage API request (JavaScript)If you're using axios in your application, you can use the following JavaScript code to call the SendMessage API:const requestHeaders = {  "X-Amz-Bearer": "ConnectionToken", // Replace "ConnectionToken" with the one you obtained from the response of CreateParticipantConnection API  "Content-type": "application/json"};const requestBody = {  "ClientToken": "unique string", // [Optional] A unique, case-sensitive identifier that you provide to ensure the idempotency of the request   "Content": message, // The actual chat message  "ContentType": "text/plain", // Currently, supported type is text/plain};axios.post(participantServiceEndpoint + "/participant/message", requestBody, {  headers: requestHeaders});Example SendEvent API request (JavaScript)If you're using axios in your application, you can use the following JavaScript code to call the SendEvent API:const requestHeaders = {  "X-Amz-Bearer": "ConnectionToken", //Replace "ConnectionToken" with the one you obtained from the response of CreateParticipantConnection API  "Content-type": "application/json"};const requestBody = {  "ClientToken": "unique string", //[Optional] A unique, case-sensitive identifier that you provide to ensure the idempotency of the request   "ContentType": "application/vnd.amazonaws.connect.event.typing", //Typing event. You can specify "application/vnd.amazonaws.connect.event.connection.acknowledged" for acknowledged event};axios.post(participantServiceEndpoint + "/participant/event", requestBody, {  headers: requestHeaders});Follow"


Question: How can I troubleshoot reverse DNS issues with Route 53 rules and outbound endpoints?

"I set up Amazon Route 53 Resolver rules and outbound endpoints. These rules and endpoints are intended to manage the reverse DNS of my virtual private cloud (VPC) at an on-premises DNS server. However, they aren't working as intended."

Answer: "I set up Amazon Route 53 Resolver rules and outbound endpoints. These rules and endpoints are intended to manage the reverse DNS of my virtual private cloud (VPC) at an on-premises DNS server. However, they aren't working as intended.Short descriptionYou can use reverse DNS lookup to return the domain name of an IP address. The format of a reverse DNS record falls under the namespace "in-addr.arpa.", where the subdomain is represented by the octets of the IP address in reverse order. The record type is pointer (PTR).For example, suppose you have a virtual private cloud (VPC) with the CIDR range 172.31.0.0/16. In the VPC, you have an instance with an IP address of 172.31.2.23. The reverse zone for this VPC is 31.172.in-addr.arpa. The reverse record of this instance's IP address is 23.2.31.172.in-addr.arpa.You can check the DNS response by running dig or nslookup. These tools allow you to test directly to the IP address and perform the reverse lookup on your behalf. In the following output examples, notice that the query is sent directly to the IP address 172.31.2.23. Both dig and nslookup perform a resolution against the name 23.2.31.172.in-addr.arpa.Using the -x parameter with dig, you can perform a reverse DNS resolution. When you use this parameter, dig automatically adds the name, class, and type arguments. Refer to the QUESTION SECTION to see that dig automatically queried the correct name (23.2.31.172.in-addr.arpa.), class (IN), and record type (PTR).dig -x 172.31.2.23:; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.amzn2.0.2 <<>> -x 172.31.2.23;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58812;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096;; QUESTION SECTION:;23.2.31.172.in-addr.arpa.    IN    PTR;; ANSWER SECTION:23.2.31.172.in-addr.arpa. 60    IN    PTR    testresolution.com.An nslookup on an IP address performs a reverse lookup:nslookup 172.31.2.2323.2.31.172.in-addr.arpa    name = testresolution.com.ResolutionUnderstand the query flowIt's important to understand the query flow when using resolver rules on a VPC and outbound endpoints. Understanding the flow can help you identify where potential issues might occur and guide your troubleshooting approach. The flow is as follows:A client in the VPC performs a reverse DNS resolution for an address within the same VPC.The query arrives at the VPC DNS resolver (VPC CIDR range plus 2).The query is matched by a resolver rule on the VPC.The query is sent by the outbound endpoint to the target IP addresses over a VPN or AWS Direct Connect connection.Note: The target IP addresses are on-premises DNS servers that manage the reverse DNS for the CIDR range of the VPC.Identify the expected and actual DNS responsesUse dig and nslookup to perform queries directly to the IP address of your on-premises DNS server. These tools try to resolve the correct record name. Be sure to note the actual DNS response code that's returned. Keep in mind that an unexpected response code might not indicate an issue with the rule or endpoint configuration. For example:NXDOMAIN might be an unexpected but valid DNS response. This response indicates that the server that's being queried doesn't contain the requested record.SERVFAIL indicates that there's a timeout or other issue on the path of the query. This response requires further investigation, as described later in this article.An unexpected answer in the ANSWER SECTION might indicate that a different rule was used.Determine if the query arrives at the VPC DNS resolverFor a query to be matched by a rule on a VPC, the query must arrive at the VPC DNS resolver. Check the VPC settings to confirm that DNS Support is enabled.Refer to the server fields in both dig and nslookup to check the resolver IP address.dig:;; SERVER: 172.31.0.2#53(172.31.0.2)nslookup:Server:172.31.0.2Find the most specific rule that's being matchedWhen the query arrives at the VPC DNS resolver, it must be matched by a rule on that VPC. When rules are evaluated, the most specific rule is matched. Internally, rules are created to cover all reverse lookups of every IP address in the source and connected VPCs. These rules don't display in the AWS Management Console. These rules are known as autodefined rules and they're created by Route 53 Resolver.Identify any autodefined rules on the VPC and connected VPCs. If you have peered VPCs or VPCs connected through a transit gateway (and DNS support is enabled), make note of all rules created for the reverse resolution of each connected CIDR.Note: Resolver creates these autodefined rules when DNS Hostnames is set to true. If you want to override an autodefined rule, you can create a conditional forwarding rule for the same domain name.If DNSSupport and DNSHostnames are enabled, note any private hosted zones associated to the VPC.Note: If the resolver forwarder rule and private hosted zone are overlapping, the resolver rule takes precedence. Then, the query is forwarded to the on-premises server.Compare your list of rules and associated private hosted zones against the query to determine which rule is selected and where the query goes.Troubleshoot your outbound endpointsConfirm that your outbound endpoints are configured to send the query to the target IP addresses specified in the rule.Confirm that the security group used by the outbound endpoints allow outbound TCP and UDP traffic to the IP addresses and ports of the on-premises DNS server.Confirm that the access control lists (ACLs) allow TCP and UDP traffic to the IP addresses and ports of the on-premise DNS server. The ACLs must also allow traffic to the ephemeral ports (1024-65535).Confirm that the route tables for the outbound endpoints have a route for the IP addresses of the on-premises server to the VPN or Direct Connect connection.Check if the outbound endpoint can send the query over the connection specified in its route tableYou can run a dig or nslookup directly to the IP address of the on-premises DNS resolver to verify that the VPN or Direct Connect connection is allowing communication. You can also send a ping to an on-premises host that allows internet control message protocol (ICMP) to rule out issues on the connection.Follow"


Question: How do I troubleshoot issues when bringing my custom container to Amazon SageMaker Studio?

I want to troubleshoot issues when building a custom Amazon SageMaker Studio.

Answer: "I want to troubleshoot issues when building a custom Amazon SageMaker Studio.ResolutionA SageMaker image is a file that identifies kernels, language packages, and other dependencies that are required to run a Jupyter notebook in SageMaker Studio. These images are used to create an environment from where you can run your Jupyter notebooks. If the built-in images provided by SageMaker don't support your use case, you can bring a custom image to use in SageMaker Studio.You might get errors when using your customer image in SageMaker Studio. These errors might result mostly from an incorrect configuration that you set up during the container image build process. Therefore, be sure that the custom image is compatible with SageMaker Studio.To do so, check the following when you build the Dockerfile:You have set the DefaultUID and DefaultGID values accurately. SageMaker Studio only supports a specific combination of DefaultUID and DefaultGID. Be sure that DefaultUID and DefaultGID are set to 1000 and 100, respectively for a non-privileged user. Be sure that the values are both set to 0 for the root user.The 'opt/.sagemakerinternal' and 'opt/ml' directories aren't used. These directories are reserved.When you create the configuration file app-image-config-input.json, be sure that the Name value for KernelSpec in this file matches the Name value for the associated image.Example Dockerfile that installs Python packages and sets the scope to non-privileged users:FROM public.ecr.aws/amazonlinux/amazonlinux:2ARG NB_USER="sagemaker-user"ARG NB_UID="1000"ARG NB_GID="100"RUN \    yum install --assumeyes python3 shadow-utils && \    useradd --create-home --shell /bin/bash --gid "${NB_GID}" --uid ${NB_UID} ${NB_USER} && \    yum clean all && \    python3 -m pip install ipykernel && \    python3 -m ipykernel installUSER ${NB_UID}You can view the error messages in Amazon CloudWatch logs when either of the following happens:Image version creation fails.You get an error when launching the image in SageMaker Studio.You can find these messages in the log group /aws/sagemaker/studio and log stream $domainID/$userProfileName/KernelGateway/$appName.Note: This article assumes that the AWS Identity and Access Management (IAM) user or role has the AmazonSageMakerFullAccess policy attached to it.Related informationCustom SageMaker image specificationsFollow"


Question: How do I deploy Lambda functions with external libraries using AWS Cloud9?

I want to add external libraries to an AWS Lambda function that I developed using AWS Cloud9. How do I do that?

Answer: "I want to add external libraries to an AWS Lambda function that I developed using AWS Cloud9. How do I do that?ResolutionNote: The following procedure uses the Python runtime as an example. A similar procedure can be used for Node.js Lambda functions.After you've created a Lambda function in your AWS Cloud9 environment, do the following:Import the external libraries' modules to your Lambda function's parent folder in your AWS Cloud9 environment1.    Open the AWS Cloud9 console.2.    Open your AWS Cloud9 environment.3.    In the left navigation pane, choose Environment. The Environment window opens.4.    Open the context (right-click) menu for your function's parent folder.Note: Your function's parent folder is listed with the same name as your function.5.    Choose Open Terminal Here. A new terminal session starts.6.    Import an external library module by running the following pip command in the new terminal:Important: Replace ModuleName with the name of the module that you want to import.python -m pip install --target=./ ModuleNameNote: To make sure that the correct versions of Python packages are installed, it's a best practice to specify a requirements.txt file in the pip command. For more information, see the Requirements file format section of the pip documentation.7.    Repeat step six for each module that you want to import. The imported modules appear in your function's parent folder.Deploy your Lambda function using the AWS ToolkitFollow the instructions in Deploying a serverless application in the AWS Cloud9 User Guide. After deploying your function, you can run your code using the additional modules that you imported.For more information, see Working with AWS serverless applications using the AWS Toolkit.Related informationWorking with AWS Lambda functions using the AWS ToolkitLocally debug a serverless application from an IDEFollow"


Question: How do I allow agents in my Amazon Connect contact center to transfer customers to a contact flow during a call?

I want agents in my Amazon Connect contact center to have an easy way to transfer customers to a contact flow during a call. How can I set up contact transfers to do that?

Answer: "I want agents in my Amazon Connect contact center to have an easy way to transfer customers to a contact flow during a call. How can I set up contact transfers to do that?Short descriptionThere are two ways to transfer voice and chat contacts to a contact flow :Using a Set disconnect flow block to transfer customers to a single contact flow after a disconnectCreating a Queue quick connect that moves contacts to a contact flow instead of a queueUsing the Queue quick connect solution allows agents to choose between more than one contact flow transfer option during a call. For example: Answering a survey or submitting feedback. There isn't a quick connect type for transferring customers to a contact flow.Note: When using the quick connect solution, transferred contacts don't enter the queue or affect the queue's metrics.ResolutionImportant: To complete the following procedure, you must log in to your Amazon Connect instance as a user that has Edit and Create permissions. For more information, see Security profiles.Create a transfer to queue contact flowLog in to your Amazon Connect instance using your access URL ( https://alias.awsapps.com/connect/login -or- https://alias.my.connect.aws).Important: Replace alias with your instance's alias.In the left navigation bar, pause on Routing. Then, choose Contact flows. The Contact flows page opens.On the Contact flows page, next to the Create contact flow button, choose the down arrow. Then, choose Create transfer to queue flow. The contact flow designer opens.In the contact flow designer, for Enter a name, enter a name for the contact flow. For example: Transfer to flow.Choose Save.For more information, see Create a new contact flow.Add a Transfer to flow contact block to the contact flowIn the contact flow designer, expand Terminate / Transfer.Drag and drop a Transfer to flow block onto the canvas.Choose the block title (Transfer to flow). The block's settings menu opens.Under Transfer, for Select a flow, choose Search for contact flow.Choose the contact flow where you want agents to transfer customers after a call.Choose Save.Do one of the following, based on your use case:If you're editing an existing Transfer to queue contact flow, then replace the Transfer to queue block with the new Transfer to flow block.-or-If you created a new Transfer to queue flow, then add and connect more contact blocks as needed. For guidance, refer to the sample contact flows.Choose Save to save a draft of the flow.Choose Publish to activate the flow immediately.For more information, see Contact Block: Transfer to queue.Note: After using the quick connect, your agents must join the customer to the call and then choose whether to disconnect. To cue the agent, consider adding an audio prompt to your Transfer to queue contact flow. You can also add an Invoke AWS Lambda function block to give agents a buffer of time before the contact is routed to the contact flow.Create and activate a Queue quick connectCreate a Queue quick connect by following the instructions in Create quick connects. While you're creating the quick connect, do the following:For the Destination, choose any queue (the contact doesn't enter the queue).For Contact flow, choose the Transfer to queue contact flow that you edited.Add the quick connect to the queues used in your contact flows by following the instructions in Allow agents to see quick connects.Confirm that the queues that include your quick connect are in a routing profile assigned to the agents who will use the quick connect. For more information, see Set up routing.For more information, see How do I allow agents in my Amazon Connect contact center to transfer contacts using the CCP?Test the setupAt the end of a contact, have the agent use the quick connect that you created. Then, join the customer to the call. The quick connect transfers the contact to the edited Transfer to queue contact flow. That flow routes the contact to the contact flow that you specified.Related informationHow routing worksTest a voice, chat, and task experiencesFollow"


Question: How do I resolve the error "The final policy size is bigger than the limit" from Lambda?

"When I set a trigger to invoke my AWS Lambda function, I get the error "The final policy size is bigger than the limit". How do I resolve the error?"

Answer: "When I set a trigger to invoke my AWS Lambda function, I get the error "The final policy size is bigger than the limit". How do I resolve the error?Short descriptionIf your Lambda function's resource-based policy is over 20 KB, then Lambda returns a The final policy size is bigger than the limit error.The error can occur when you add policy statements to your function's resource-based policy by doing either of the following:Manually using the add-permission AWS Command Line Interface (AWS CLI) command.Creating resources for other AWS services that need permission to access your function.To resolve the error, reduce your function's policy's size by removing repetitive policy statements and replacing them with consolidated statements that use wildcards (*). For more information, see Lambda quotas and Cleaning up resource-based policies.ResolutionNote: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent AWS CLI version.Review your function's resource-based policiesNote: For the following commands, replace my-function with your function's name or Amazon Resource Name (ARN).1.    Run the following get-policy AWS CLI command to find and review your Lambda function's resource-based policy:$ aws lambda get-policy --function-name my-functionNote: You can also use the command line JSON processor, jq, in the get-policy command to write advanced queries. For information on how to download and install jq, see Download jq on the jq website on GitHub.Example get-policy command that uses jq to format a Lambda function's policy as a JSON file$ aws lambda get-policy --function-name my-function | jq '.Policy|fromjson'Example get-policy command that uses jq to find the size of a Lambda function's policy$ aws lambda get-policy --function-name my-function | jq -r '.Policy' | wc -cExample get-policy command that uses jq to find the statement ID (Sid) of certain policy statementsReplace events.amazonaws.com with the AWS service that invokes your function.$ aws lambda get-policy --function-name my-function | jq '.Policy | fromjson | .Statement[] | select(.Principal.Service=="events.amazonaws.com") | .Sid'Example get-policy command that uses jq to get the Sid of resources whose names start with the same stringReplace arn:aws:events:region:account-id:rule/test- with a string shared by the ARNs of resources across multiple, repetitive policy statements.$ aws lambda get-policy --function-name my-function | jq '.Policy| fromjson| .Statement[] | select(.Condition.ArnLike."AWS:SourceArn" | startswith("arn:aws:events:region:account-id:rule/test-")) | .Sid'2.    In the resource-based policy, identify policy statements that you can replace with a wildcard. Note the Sid of each policy statement.Remove repetitive policy statementsRun the following remove-permission AWS CLI command to remove each repetitive policy statement. Replace my-function with your function's name or ARN. Replace sid with the Sid of the policy statement that you want to remove.$ aws lambda remove-permission --function-name my-function --statement-id sidAdd policy statements that use a wildcard (*)Run the following add-permission AWS CLI command to add new, consolidated policy statements that include a wildcard (*), Replace my-function with your function's name or ARN. Replace sid with a new Sid of any value. Replace events.amazonaws.com with the AWS service or account principal that invokes your function. Replace arn:aws:events:region:account-id:rule/test-* with an ARN string (plus a wildcard) shared by the resources that you're granting permissions to.$ aws lambda add-permission --function-name my-function \--statement-id 'sid' \--action 'lambda:InvokeFunction' \--principal 'events.amazonaws.com' \--source-arn 'arn:aws:events:region:account-id:rule/test-*'Note: Triggers with wildcards in the resource-based policy might not be visible in the Lambda console. For more information, see Event-driven invocation.For more information, see Granting function access to AWS services.Related informationIAM JSON policy elements: resourceControlling command output from the AWS CLI (AWS CLI User Guide)Why doesn't my Amazon S3 event notification invoke my Lambda function?How do I stop and start Amazon EC2 instances at regular intervals using Lambda?Follow"


Question: How do I activate reverse DNS functionality for Route 53 with a PTR record?

I need to configure reverse domain name service (DNS) resolution for a server using Amazon Route 53. How can I do this?

Answer: "I need to configure reverse domain name service (DNS) resolution for a server using Amazon Route 53. How can I do this?Short descriptionTo configure reverse DNS resolution for a Simple Mail Transfer Protocol (SMTP) server, you must first determine the appropriate method for your use case:If you have an on-premises SMTP server and you use non-AWS resources, your IP addresses might be owned by a third party. The third party might be another cloud computing platform or your internet service provider (ISP). In this case, you must use the method provided by the IP address owner to configure reverse DNS. The IP address owner might require you to create a reverse DNS record and provide only the name servers to them for delegation. In this case, complete the Resolution steps in the "Using on-premises SMTP servers" section. You must configure Route 53 to respond to reverse DNS lookup queries for your server by creating a public hosted zone. Then, you must add a pointer (PTR) record in it.If you have an SMTP server hosted in Amazon Virtual Private Cloud (Amazon VPC) and you use AWS-provided Elastic IP addresses for your servers, then complete the Resolution steps in the "Using SMTP servers hosted in Amazon VPC" section to configure reverse DNS.ResolutionUsing on-premises SMTP serversNote: This resolution uses the following example IP addresses for the SMTP server: 1.2.3.4 (IPv4) and 2000:1234:5678:9012:3456:7890:1234:5678 (IPv6).Create a public hosted zoneCreate a public hosted zone for your server’s IP address. For example: 3.2.1.in-addr.arpa (IPv4) or 2.1.0.9.8.7.6.5.4.3.2.1.0.0.0.2.ip6.arpa (IPv6).Create a record set and PTR recordCreate a record set for your hosted zone.Create a PTR record for your SMTP server.For Name, enter the reversed IP address plus in-addr.arpa (IPv4) or ip6.arpa (IPv6). For example, 4.3.2.1.in-addr.arpa (IPv4) or 8.7.6.5.4.3.2.1.0.9.8.7.6.5.4.3.2.1.0.9.8.7.6.5.4.3.2.1.0.0.0.2.ip6.arpa (IPv6).For Type, choose PTR – Pointer.For Value, enter the fully qualified domain name (FQDN) of the SMTP server. For example, mail.example.com.Note: If your domain has multiple IP blocks, you must create additional reverse hosted zones with corresponding PTR records to resolve the IP addresses.Set up delegationAfter you create the PTR record, you must ask the IP address owner to set up delegation to the name servers in your reverse hosted zone. To locate name server details, follow these steps:Open the Route 53 console.In the navigation pane, choose Hosted zones.Select your hosted zone.For Type, choose NS.Note the record’s Value.Note: The time for this new configuration to take effect depends on the time to live (TTL) records of the previous NS record. Note that the TTL records of the previous name server (NS) record might be cached in end-user local DNS servers.Using SMTP servers hosted in Amazon VPCCreate a forward DNS record (record type A) that points to the appropriate Elastic IP address.Create or update the reverse DNS record for an Elastic IP address:For AWS Elastic IP addresses in all Regions – Update the reverse DNS address using the Amazon Elastic Compute Cloud (Amazon EC2) console or the AWS Command Line Interface (AWS CLI). Users can manage Reverse DNS for AWS Elastic IP addresses (IPv4 only). For IPv6 addresses, users are to open a request to remove reverse DNS and email sending limitations. Include your IPv6 addresses and reverse DNS records with your request.Related informationWhy can't my server receive email after I created an MX record for my SMTP server in Route 53?Follow"


Question: How do I save my work in Amazon Lightsail?

I want to create a backup of my Amazon Lightsail instance to save my work.

Answer: "I want to create a backup of my Amazon Lightsail instance to save my work.ResolutionCreate a snapshot of your Lightsail instance to use as a backup. Lightsail snapshots preserve the state of your instance at the time the snapshot was taken.After you create a snapshot, you can delete the running Lightsail instance. If you need that instance again, you can create a new Lightsail instance from that snapshot.Note: Snapshots are billed at a lower rate than running Lightsail instances.Related informationSnapshots in Amazon LightsailAmazon Lightsail pricingFollow"


Question: Why does my Amazon EMR application fail with an HTTP 403 "Access Denied" AmazonS3Exception?

"When I submit an application to an Amazon EMR cluster, the application fails with an HTTP 403 "Access Denied" AmazonS3Exception."

Answer: "When I submit an application to an Amazon EMR cluster, the application fails with an HTTP 403 "Access Denied" AmazonS3Exception.ResolutionIf permissions are not configured correctly, you might get an "Access Denied" error on Amazon EMR or Amazon Simple Storage Service (Amazon S3). The error looks similar to the following message:java.io.IOException: com.amazon.ws.emr.hadoop.fs.shaded.com.amazonaws.services.s3.model.AmazonS3Exception: Access Denied (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied; Request ID: 8B28722038047BAA; S3 Extended Request ID: puwS77OKgMrvjd30/EY4CWlC/AuhOOSNsxfI8xQJXMd20c7sCq4ljjVKsX4AwS7iuo92C9m+GWY=), S3 Extended Request ID: puwS77OKgMrvjd30/EY4CWlC/AuhOOSNsxfI8xQJXMd20c7sCq4ljjVKsX4AwS7iuo92C9m+GWY=First, check the credentials or role specified in your application codeRun the following command on the EMR cluster's master node. Replace s3://doc-example-bucket/abc/ with your Amazon S3 path.aws s3 ls s3://doc-example-bucket/abc/If this command is successful, then the credentials or role specified in your application code are causing the "Access Denied" error. Confirm that your application is using the expected credentials, or assuming the expected role, and that it has access to the Amazon S3 path. Verify that the role has permissions to the Amazon S3 path by assuming the AWS Identity and Access Management (IAM) role using the AWS CLI. Then, perform a sample request to the S3 path.If this command fails, confirm that you're using the most recent version of the AWS Command Line Interface (AWS CLI). Then, check the following to resolve the "Access Denied" error:Check the policy for the Amazon EC2 instance profile roleIf the Amazon Elastic Compute Cloud (Amazon EC2) instance profile doesn’t have the required read and write permissions on the S3 buckets, you might get the “Access Denied” error.Note: By default, applications inherit Amazon S3 access from the IAM role for the Amazon EC2 instance profile. Be sure that the IAM policies attached to this role allow the required S3 operations on the source and destination buckets.To troubleshoot this issue, check if you have the required read permission by running the following command:$ aws s3 ls s3://doc-example-bucket/myfolder/Your output might look like the following:An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied-or-Run the following command:$ hdfs dfs -ls s3://doc-example-bucket/myfolderYour output might look like the following:ls: com.amazon.ws.emr.hadoop.fs.shaded.com.amazonaws.services.s3.model.AmazonS3Exception: Access Denied (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied; Request ID: RBT41F8SVAZ9F90B; S3 Extended Request ID: ih/UlagUkUxe/ty7iq508hYVfRVqo+pB6/xEVr5WHuvcIlfQnFf33zGTAaoP2i7cAb1ZPIWQ6Cc=; Proxy: null), S3 Extended Request ID: ih/UlagUkUxe/ty7iq508hYVfRVqo+pB6/xEVr5WHuvcIlfQnFf33zGTAaoP2i7cAb1ZPIWQ6Cc=Be sure that the instance profile role has the required read and write permissions for the S3 buckets. For example, the S3 actions in the following IAM policy provide the required read and write access to the S3 bucket doc-example-bucket:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "ListObjectsInBucket",      "Effect": "Allow",      "Action": [        "s3:ListBucket"      ],      "Resource": [        "arn:aws:s3:::doc-example-bucket"      ]    },    {      "Sid": "AllObjectActions",      "Effect": "Allow",      "Action": "s3:*Object*",      "Resource": [        "arn:aws:s3:::doc-example-bucket/*"      ]    }  ]}Check the IAM role for the EMRFS role mappingIf you use a security configuration to specify IAM roles for EMRFS, then you’re using role mapping. Your application inherits the S3 permissions from the IAM role based on the role-mapping configuration.The IAM policy attached to these roles must have the required S3 permissions on the source and destination buckets. To specify IAM roles for EMRFS requests to Amazon S3, see Set up a security configuration with IAM roles for EMRFS.Check the Amazon S3 VPC endpoint policyIf the EMR cluster's subnet route table has a route to an Amazon S3 VPC endpoint, then confirm that the endpoint policy allows the required Amazon S3 operations.To check and modify the endpoint policy using CLI:Run the following command to review the endpoint policy. Replace vpce-xxxxxxxx with your VPC ID.aws ec2 describe-vpc-endpoints --vpc-endpoint-ids "vpce-xxxxxxxx"If necessary, run the following command to upload a modified endpoint policy.  Replace the VPC ID and JSON file path.aws ec2 modify-vpc-endpoint --vpc-endpoint-id "vpce-xxxxxxxx" --policy-document file://policy.jsonTo check and modify the endpoint policy using the Amazon VPC console:Open the Amazon VPC console.In the navigation pane, choose Endpoints.Select the Amazon S3 endpoint (the one that's on the EMR cluster's subnet route table). Then, choose the Policy tab to review the endpoint policy.To add the required Amazon S3 actions, choose Edit Policy.Check the S3 source and destination bucket policiesBucket policies specify the actions that are allowed or denied for principals. The source and destination bucket policies must allow the EC2 instance profile role or the mapped IAM role to perform the required Amazon S3 operations.To check and modify the bucket policies using CLI:Run the following command to review a bucket policy. Replace doc-example-bucket with the name of the source or destination bucket.aws s3api get-bucket-policy --bucket doc-example-bucketIf necessary, run the following command to upload a modified bucket policy. Replace the bucket name and JSON file path.aws s3api put-bucket-policy --bucket doc-example-bucket --policy file://policy.jsonTo check and modify the bucket policies using the Amazon S3 console:Open the Amazon S3 console.Choose the bucket.Choose the Permissions tab.Choose Bucket Policy to review and modify the bucket policy.Accessing S3 buckets in another accountImportant: If your application accesses an S3 bucket that belongs to another AWS account, then the account owner must allow your IAM role on the bucket policy.For example, the following bucket policy gives all IAM roles and users in emr-account full access to s3://doc-example-bucket/myfolder/.{  "Id": "MyCustomPolicy",  "Version": "2012-10-17",  "Statement": [    {      "Sid": "AllowRootAndHomeListingOfCompanyBucket",      "Principal": {        "AWS": [          "arn:aws:iam::emr-account:root"        ]      },      "Action": [        "s3:ListBucket"      ],      "Effect": "Allow",      "Resource": [        "arn:aws:s3:::doc-example-bucket"      ],      "Condition": {        "StringEquals": {          "s3:prefix": [            "",            "myfolder/"          ],          "s3:delimiter": [            "/"          ]        }      }    },    {      "Sid": "AllowListingOfUserFolder",      "Principal": {        "AWS": [          "arn:aws:iam::emr-account:root"        ]      },      "Action": [        "s3:ListBucket"      ],      "Effect": "Allow",      "Resource": [        "arn:aws:s3:::doc-example-bucket"      ],      "Condition": {        "StringLike": {          "s3:prefix": [            "myfolder/*"          ]        }      }    },    {      "Sid": "AllowAllS3ActionsInUserFolder",      "Principal": {        "AWS": [          "arn:aws:iam::emr-account:root"        ]      },      "Effect": "Allow",      "Action": [        "s3:*"      ],      "Resource": [        "arn:aws:s3:::doc-example-bucket/myfolder/*",        "arn:aws:s3:::doc-example-bucket/myfolder*"      ]    }  ]}Related informationWhy does my Spark or Hive job on Amazon EMR fail with an HTTP 503 "Slow Down" AmazonS3Exception?Why does my Amazon EMR application fail with an HTTP 404 "Not Found" AmazonS3Exception?Error responses (Amazon S3 API reference)How do I troubleshoot 403 Access Denied errors from Amazon S3?Follow"


Question: How can I troubleshoot AWS Config console error messages?

My AWS Config console returns an error or isn't working as expected.

Answer: "My AWS Config console returns an error or isn't working as expected. Short descriptionIf you perform an action in the AWS Config console and receive one of the following error messages, then see the related section for troubleshooting:"An error has occurred with AWS Config. Contact AWS Support.""We are unable to complete the request at this time. Try again later or contact AWS Support.""AWS Config is currently experiencing unusually high traffic. Try your request again or contact AWS Support.""An unexpected internal error occurred with AWS Config. Try again or contact AWS Support if the error persists."ResolutionAn error has occurred with AWS Config. Contact AWS Support.This can occur if the AWS Identity and Access Management (IAM) entity performing an action on the AWS Config console doesn't have the necessary permissions. For example, config:PutConfigRule, iam:PassRole, or ssm:ListDocuments permissions. This error also can occur if your AWS Config aggregator contains duplicate accounts or if AWS Systems Manager parameters aren't valid.AWS API Error CodeCloudTrail Error MessageRelated AWS Config APIDescriptionResolutionInsufficientDeliveryPolicyExceptionInsufficient delivery policy to s3 bucket:<Bucket Name>, unable to write to bucket, provided s3 key prefix is 'null'.PutDeliveryChannelAmazon Simple Storage Service (Amazon S3) bucket policy lacks permission to write into the target bucket.Check the Amazon S3 bucket policy, and then verify that it allows the config.amazonaws.com service to write into the target bucket. Then, review the IAM entity permission, and then use the AWS Config Full access policy. Finally, verify that the IAM entity has permissions to write to the s3:GetBucketAcl and s3:PutObject* buckets.InvalidParameterValueExceptionYour configuration aggregator contains duplicate accounts. Delete the duplicate accounts and try again.PutConfigurationAggregatorYour configuration aggregator contains duplicate accounts.If you added a new aggregator or edited an existing one using the same account ID, delete the duplicate account, and then try again. For more information, see Setting up an aggregator using the console.AccessDeniedThe user:arn:aws:sts::Example_Account_ID:assumed-role/Example_IAM_Role_Name is not authorized to perform: config:PutConfigurationRecorder with an explicit deny.PutConfigurationRecorderAn AWS Control Tower preventive guardrail is enforced with AWS Organizations using Service Control Policies (SCPs) that disallow configuration changes to AWS Config.Verify AWS resource access with your primary account administrators.InvalidParameterValueExceptionRemediationConfiguration(s) for AWS Config Rule(s) <Config_Rule_Name> are missing required document parameters. Specify all required document parameters and try again.PutRemediationConfigurationsThe required Systems Manager parameter is empty, or one or more of the specified parameters aren't valid.Add the required Systems Manager parameters. For more information, see Systems Manager Automation runbook reference.We are unable to complete the request at this time. Try again later or contact AWS Support.This error can occur if you exceed the AWS Config aggregator limit, or if you're calling the StartConfigRulesEvaluation API more than one time every minute.AWS API Error CodeCloudTrail Error MessageRelated AWS Config APIDescriptionResolutionLimitExceededExceptionThe configuration aggregator '<aggregator_name>' could not be created because the account already contains '50' configuration aggregators. Consider deleting configuration aggregators or contact AWS Config to increase the limit."PutConfigurationAggregatorThis error indicates that the number of the aggregators exceeds the limit.The default limit for configuration aggregators is 50. You can either delete an aggregator or request a limit increase. For more information, see Service limits.LimitExceededExceptionYou have exceeded the maximum request rate. Try again at a later time.StartConfigRulesEvaluationThis error indicates you're calling the StartConfigRulesEvaluation API more than one time every minute, or when another evaluation is in progress.The StartConfigRulesEvaluation API call is limited to one time every minute. Wait for the current evaluation to complete, or wait one minute, and then try again.AWS Config is currently experiencing unusually high traffic. Try your request again or contact AWS Support.This error can occur if you are using the API call GetResourceConfigHistory or ListDiscoveredResources with automation.AWS API Error CodeCloudTrail Error MessageRelated AWS Config APIDescriptionResolutionThrottlingExceptionRate exceededGetResourceConfigHistoryUsing the API call GetResourceConfigHistory with automation can cause an issue if the allowed limit is exceeded.If your automation retrieves the old state of your resources, then use the earlierTime parameter to limit the history period. Limit the history period using a timestamp with the GetResourceConfigHistory API. Or, if your automation determines the current configuration of your resources, consider using the BatchGetResourceConfig API call instead of GetResourceConfigHistory.ThrottlingExceptionRate exceededListDiscoveredResourcesUsing the API call ListDiscoveredResources with an automation can cause an issue if there is a high rate within a short interval that exceeds the throttle rate in the account per Region.Reduce the frequency of API calls by implementing a sleep time. For more information, see Managing AWS Lambda function concurrency.Note: In addition to these best practices, you can also implement exponential backoff, and then retry your request.An unexpected internal error occurred with AWS Config. Try again or contact AWS Support if the error persistsThis error can occur if you switched to a different AWS Region, or attempted to delete a remediation while there is a remediation in progress.AWS API Error CodeCloudTrail Error MessageRelated AWS Config APIDescriptionResolutionNoSuchConfigRuleExceptionThe ConfigRule '<Config rule name>' provided in the request isn't valid. Please check the configRule name.GetComplianceDetailsByConfigRuleYou might receive this error in AWS Config rules if you switched to a different AWS Region, because the rule doesn't exist in that Region.Switch back to the AWS Region that contains the AWS Config rule. For more information, see Choosing a Region.RemediationInProgressExceptionRemediation action is in progress.DeleteRemediationConfigurationYou deleted a remediation while there is a remediation in progress.If you deleted a remediation action when a remediation was in progress, you can cancel the execution with the stop-automation-execution command. Or, you can wait, and then try again later.NoSuchRemediationConfigurationExceptionNo RemediationConfiguration for rule EXAMPLE_Config_Rule_Name exists.DeleteRemediationConfigurationThe PutRemediationConfigurations API call ResourceType parameter was specified in creation but not in deletion.If you use the ResourceType parameter in the PutRemediationConfigurations API, you must also use the ResourceType parameter in the DeleteRemediationConfiguration API.Related informationAWS Config common errorsAWS CloudTrail common errorsAWS Lambda errorsWorking with CloudTrail log filesTroubleshooting Systems Manager AutomationFollow"


Question: Why am I getting API Gateway 401 Unauthorized errors after creating a Lambda authorizer?

"My Amazon API Gateway API is returning 401 Unauthorized errors after I created an AWS Lambda authorizer for it. Why is this happening, and how do I troubleshoot the issue?"

Answer: "My Amazon API Gateway API is returning 401 Unauthorized errors after I created an AWS Lambda authorizer for it. Why is this happening, and how do I troubleshoot the issue?Short descriptionNote: API Gateway can return 401 Unauthorized errors for many reasons. This article addresses only 401 Unauthorized response errors returned by API Gateway without calling the authorizer Lambda function.When an API Gateway API with a Lambda authorizer receives an unauthorized request, API Gateway returns a 401 Unauthorized response.For token-based Lambda authorizers401 Unauthorized errors usually occur when a required token is missing or isn't validated by the authorizer's token validation expression.For request parameter-based Lambda authorizers401 Unauthorized errors usually occur when configured identity sources are missing, null, empty, or not valid.To troubleshoot this type of error, verify the information that must be included in requests to your API by reviewing your Lambda authorizer's configuration. Then, test the authorizer by calling your API with the required header and token value or the identity sources.Note: For example Lambda authorizer setups, see Create a token-based Lambda authorizer function and Create a request-based Lambda authorizer function.ResolutionReview the Lambda authorizer's configuration1.    Open the API Gateway console.2.    On the APIs pane, choose the name of your API.3.    In the navigation pane, under the name of your API, choose Authorizers. The Authorizers page opens.4.    Review the authorizer's configuration for one of the following based on your use case:For token-based Lambda authorizersIf Lambda Event Payload is set as Token, then check the Token Source value. The Token Source value must be used as the request header in calls to your API.Important: If you entered a regular expression for Token Validation, then API Gateway validates the token against this expression. For example, if you entered the regular expression \ w{5}, then only token values with 5-character alphanumeric strings are successfully validated.-or-For request parameter-based Lambda authorizersIf Lambda Event Payload is set as Request, then check the configured Identity Sources. The identity sources can be headers, query strings, multi-value query strings, stage variables, or $context variables.Important: If Authorization Caching is turned on, then requests to your API are validated against all the configured identity sources.5.    If you have Authorization Caching turned on (for example, "Authorization cached for 1 minute"), turn off caching for testing in the next step.For more information, see Configure a Lambda authorizer using the API Gateway console.Deploy your APIIf you changed your Lambda authorizer's configuration or any other API settings, redeploy your API to commit the changes.Test your Lambda authorizerTo test your Lambda authorizer, make a test call to your API by doing one of the following:Important: Make sure that you format the request according to your Lambda authorizer's configuration.To test a Lambda authorizer using the API Gateway console1.    Open the API Gateway console.2.    On the APIs pane, choose the name of your API.3.    In the navigation pane, under the name of your API, choose Authorizers.4.    On the Authorizers page, choose Test for your authorizer.5.    In the Test Authorizer dialog box, do one of the following based on your use case:For token-based Lambda authorizers1.    Choose Test without giving any value for Authorization Token. API Gateway returns a Response Code: 401 because Authorization Token is empty.2.    If Token Validation with regular expression \ w{5} is configured, enter a value that isn't valid, such as "abc123", as Authorization Token. Then, choose Test. API Gateway returns a Response Code: 401 because Authorization Token doesn’t satisfy the Token Validation expression.3.    For the Authorization Token value, enter allow and then choose Test. API Gateway returns a Response Code: 200 message.-or-For request parameter-based Lambda authorizers1.    Delete the Request Parameters and choose Test.  API Gateway returns a Response Code: 401 because Request Parameters  are missing.2.    For Request Parameters, enter headerValue1, queryValue1, and stageValue1 and choose Test. API Gateway returns a Response Code: 200 message.To test a Lambda authorizer using Postman or curlFor instructions on how to test a Lambda authorizer using the Postman app, see Call an API with API Gateway Lambda authorizers.For more information about curl, see the cURL project website.Note:If you turned off Authorization Caching for your Lambda authorizer before testing, you can reactivate it after testing. If you reactivate Authorization Caching, make sure that you redeploy your API to commit the changes.If you receive Cross-Origin Resource Sharing (CORS) errors from the Lambda authorizer, you can add the CORS headers for the DEFAULT 4XX API Gateway responses. For more information, see How do I troubleshoot CORS errors from my API Gateway API?Related informationControlling and managing access to a REST API in API GatewayHow do I turn on Amazon CloudWatch Logs for troubleshooting my API Gateway REST API or WebSocket API?Follow"


Question: How do I resolve the "cannot restore index [.kibana]" error in Amazon OpenSearch Service?

"When I try to restore indices from manual snapshots in Amazon OpenSearch Service, the restoration fails with an error message. How do I resolve this?"

Answer: "When I try to restore indices from manual snapshots in Amazon OpenSearch Service, the restoration fails with an error message. How do I resolve this?ResolutionAmazon OpenSearch Service monitors the .kibana index and recreates the index when it's deleted. This behavior can cause the restoration to fail with the following error message:{    "error": {        "root_cause": [{            "type": "snapshot_restore_exception",            "reason": "[repository-name:snapshot-name/1A2B34aZQFWQpFOYYJfxmQ] cannot restore index [.kibana] because an open index with same name already exists in the cluster. Either close or delete the existing index or restore the index under a different name by providing a rename pattern and replacement name"        }],        "type": "snapshot_restore_exception",        "reason": "[repository-name:snapshot-name/1A2B34aZQFWQpFOYYJfxmQ] cannot restore index [.kibana] because an open index with same name already exists in the cluster. Either close or delete the existing index or restore the index under a different name by providing a rename pattern and replacement name"    },    "status": 500}To resolve this issue, perform the following steps:1.    Restore the indices and rename the .kibana index, like this:# restore indices.   $ curl -XPOST -H 'Content-Type: application/json' 'https://your-domain-end-point/_snapshot/your-repository-name/your-snapshot-name/_restore' -d'{    "indices": "*",    "ignore_unavailable": true,    "include_global_state": true,    "rename_pattern": ".kibana",    "rename_replacement": "restored_.kibana"}In this example, the .kibana index is renamed to "restored_.kibana".2.    Use the _reindex API operation to rename "restored_.kibana" back to ".kibana", like this:# reindex restored_.kibana to .kibana $ curl -XPOST -H 'Content-Type: application/json' 'https://your-domain-end-point/_reindex' -d'{    "source": {        "index": "restored_.kibana"    },    "dest": {        "index": ".kibana"    }}You can now restore your indices from a manual snapshot.Follow"