Question: Why is my Amazon ECS or Amazon EC2 instance unable to join the cluster?

I can't register my Amazon Elastic Compute Cloud (Amazon EC2) instance with an Amazon Elastic Container Service (Amazon ECS) Cluster.

Answer: "I can't register my Amazon Elastic Compute Cloud (Amazon EC2) instance with an Amazon Elastic Container Service (Amazon ECS) Cluster.Short descriptionYour Amazon EC2 instance can't register with or join an Amazon ECS cluster because of one or more of the following reasons:The ECS endpoint can't access the Domain Name System (DNS) hostname of the instance publicly.Your public subnet configurations are incorrect.Your private subnet configurations are incorrect.Your VPC endpoints are incorrectly configured.Your security groups don't allow network traffic.The EC2 instance doesn't have the required AWS Identity and Access Management (IAM) permissions. Or, the ecs:RegisterContainerInstance API call is denied.The instance user data for your ECS container is incorrectly configured.The ECS agent is stopped or not running on the instance.The launch configuration of the Auto Scaling group isn't correct (if your instance is part of an Auto Scaling group).The Amazon Machine Image (AMI) that you use for your instance doesn't meet the prerequisites.ResolutionUse the AWSSupport-TroubleshootECSContainerInstance AWS Systems Manager runbook to troubleshoot the common issues that are listed in the Short description section. If the runbook's output doesn't provide recommendations, then use the manual troubleshooting approaches the following Resolution sections.Use the Systems Manager Automation runbookUse the AWSSupport-TroubleshootECSContainerInstance runbook to troubleshoot the EC2 instance that fails to register with the ECS cluster. This automation checks for potential issues with the following resources:The user data for the instance contains the correct cluster information.The instance profile contains the required permissions.The network is correctly configuredNote: Be sure to use the AWSSupport-TroubleshootECSContainerInstance runbook in the same AWS Region where your ECS Cluster and EC2 instance are located.Open the AWS Systems Manager console.In the navigation pane, under Change Management, choose Automation.Choose Execute automation.Choose the Owned by Amazon tab.Under Automation document, search for TroubleshootECSContainerInstance.Select the AWSSupport-TroubleshootECSContainerInstance card.Note: Select the radio button and not the hyperlinked automation name.Choose Next.For Execution automation document, choose Simple execution.In the Input parameters section, for AutomationAssumeRole, enter the Amazon Resource Name (ARN) of the role that allows Systems Manager Automation to perform actions.Note: If you don't specify an IAM role, then Systems Manager Automation uses the permissions of the IAM user or role that runs the runbook. For more information about creating the assume role for Systems Manager Automation, see Method 2: Use IAM to configure roles for Automation. Be sure that the AutomationAssumeRole or the IAM role has the following permissions: ec2:DescribeIamInstanceProfileAssociations, ec2:DescribeInstanceAttribute, ec2:DescribeInstances, ec2:DescribeNetworkAcls, ec2:DescribeRouteTables, ec2:DescribeSecurityGroups, ec2:DescribeSubnets, ec2:DescribeVpcs, ec2:DescribeVpcEndpoints, iam:GetInstanceProfile, iam:GetRole, iam:SimulateCustomPolicy, and iam:SimulatePrincipalPolicy.For ClusterName, enter the cluster name where the EC2 instance failed to register.For InstanceId, enter the EC2 Instance ID that failed to register.Choose Execute.The runbook's output provides troubleshooting steps and recommendations.Verify the status of the Amazon ECS agent on the Amazon Linux 2 instanceRun the following command to check whether the Amazon ECS container agent on the instance is running:sudo systemctl status ecsIf the container agent isn't running on your instance, then run the following command to start the agent:sudo systemctl start ecsThe output of the command output must look similar to the following:ecs start/running, process 23403Check launch configurationsIf the instance that you're launching is part of an Auto Scaling group, then confirm that the Auto Scaling group's launch configuration is correct. For more information, see Step 5 in Refreshing an Amazon ECS container instance cluster with a new AMI.Check the AMI of your instanceIf the AMI that you use for the EC2 instance is a copied or custom AMI, then confirm that the instance has the following components:A modern Linux distribution running at least version 3.10 of the Linux kernel.Latest version of the Amazon ECS Linux container agent.A Docker daemon running at least version 1.9.0 and any Docker runtime dependencies (from the Docker website). To view the current Docker version, run the command sudo docker version. For information about installing the latest Docker version on your particular Linux distribution, see Docker documentation for Install Docker engine on the Docker website.The Amazon ECS optimized AMIs are preconfigured with these requirements. It's a best practice to use Amazon ECS optimized AMIs unless your application requires version that's not yet available in that AMI.Verify the log filesIf the issue still persists, then use Amazon ECS logs collector to collect the logs, and then review the logs to find the cause. You can also check log files on the container host for the container agent and Docker.To view the log files for the container agent and Docker, run the following commands:sudo cat /var/log/ecs/ecs-agent.log.YYYY-MM-DD-**sudo cat /var/log/dockerTroubleshooting common errorsError: Launching a new EC2 instance. Status Reason: This account is currently blocked and not recognized as a valid account. Please contact aws-verification@amazon.com if you have questions. Launching EC2 instance failed.Contact aws-verification@amazon.com. Be sure to mention that you must unblock your account.Error: re-registering: ClientException: Container instance 12345678910xxxxxxxxxxxx is inactive.\n\tstatus code: 400, request id: 012345678a-012345b-012ab-0a1-9f645f4s5c12" module=agent.goYou get this error when the ECS agent can't register the EC2 container instance with the ECS cluster because the EC2 instance is inactive now. This error is related to the application that's running on the instance. To understand the cause of the error, check the application. If the error persists, then check the ECS agent logs.Error: Few instances are able to join the cluster but with the same configurations, other instance are not able to join the cluster.This error might occur due to a ThrottlingException that results when a specific API call exceeds the rate limit. To resolve this error, increase the account-level rate limit. Check for APIs, such as RegisterTargets and RegisterContainerInstance.Error: After changing the instance type, new instances are unable to join the cluster.This error occurs when the ECS agent is stuck in Pending state and can't change the instance type. Unlike some EC2 instances, you can't stop the ECS instance, change the instance type, and then start it again. To change the instance type in Amazon ECS, complete the following steps:Terminate the container instance.Launch a new container instance with the new instance size. It's a best practice to launch the instance with Amazon ECS optimized Amazon Linux 2 AMI for your cluster.Or, you can create a new launch configuration. Then, update the launch configuration in the Auto Scaling group.For more information, see How do I change my container instance type in Amazon ECS?Error: Unable to register as a container instance with ECS: AccessDeniedException: User: arn:aws:sts::1122334455:assumed-role/ecsInstanceRole/i-00aa11bb22cc33def is not authorized to perform: ecs:RegisterContainerInstance on resource: arn:aws:ecs:us-east-1:1122334455:cluster/exampleCluster . status code: 400, request id: 0a123456-7899-10101-a987-6543210deff-or-Error: 2019-06-29T16:10:09Z [ERROR] Error re-registering: AccessDeniedException: User: arn:aws:sts::1122334455:assumed-role/ecsInstanceRole/i-0052b2e858b1891ef is not authorized to perform: ecs:RegisterContainerInstance on resource: arn:aws:ecs:us-east-1:1122334455:cluster/exampleCluster status code: 400, request id: 0a123456-7899-10101-a987-123456pqrsThese errors occur due to missing IAM permissions. To resolve these errors, review the instructions in Amazon ECS container instance IAM role.Also, run the AWSSupport-TroubleshootECSContainerInstance runbook to see which permissions are missing from the container instance role.Related informationCreate a virtual private cloudWhy are my Amazon ECS container instances with Amazon Linux 1 AMIs disconnected?Amazon ECS troubleshootingCreating your own runbooksFollow"


Question: Why did Windows activation fail on my EC2 Windows instance?

I received a "Windows activation failed" message on my Amazon Elastic Compute Cloud (Amazon EC2) Windows instance.

Answer: "I received a "Windows activation failed" message on my Amazon Elastic Compute Cloud (Amazon EC2) Windows instance.Short descriptionWindows instances use Microsoft Key Management Service (Microsoft KMS) on Amazon Web Services (AWS) for activation. You might get a Windows activation error message if your instance can’t reach the Microsoft KMS server. Or, there might be an issue with the Microsoft KMS client configuration.You can either use an AWS Systems Manager Automation document or follow a manual process to activate Windows.ResolutionActivate Windows using a Systems Manager Automation documentThe AWSSupport-ActivateWindowsWithAmazonLicense Automation document activates an Amazon EC2 Windows instance with a license provided by Amazon. The automation checks the current status of Windows for your instance, and then activates Windows if the status is inactive.Note: This solution isn't applicable for Bring Your Own License (BYOL) Windows instances. To use your own license, see Microsoft licensing on AWS.1.    Open the AWS Systems Manager console. Be sure to select the same Region as the EC2 Windows instance that requires Windows activation.2.    Choose Automation from the navigation pane, and then choose Execute automation.3.    In the search field, enter ActivateWindowsWithAmazonLicense. Select the AWSSupport-ActivateWindowsWithAmazonLicense Automation document, and then choose Next.4.    For Execute automation document, choose Simple execution.5.    For Input parameters, turn on Show interactive instance picker.6.    Choose your EC2 instance.Note: If you don't see your instance in the list, then the instance isn't activated for Systems Manager. Review the prerequisites for using Systems Manager to manage your Amazon EC2 instances.If you don't want to activate Systems Manager, or if the instance isn't available in Input parameters, then turn off Show interactive instance picker. For InstanceID, enter the ID for your impaired EC2 instance. For AllowOffline, choose True.Important: If you set AllowOffline to True, your EC2 instance stops and restarts. Data in instance store volumes is lost. The public IP address changes if you aren’t using an Elastic IP address.7.    Choose Execute.8.    To monitor the execution progress, open the Systems Manger console, and then choose Automation from the navigation pane. Choose the running automation, and then review the Executed steps. To view the automation output, expand Outputs.Activate Windows manually1.    Update EC2Config, or run the EC2Launch initialization script.For Windows Server 2012 R2 and earlier: Update EC2Config, and then run these commands to restart the service:net stop ec2confignet start ec2configFor Windows Server 2016 and later: Run this command to set the correct route to the Microsoft KMS server:PS C:>Import-Module "C:\\ProgramData\\Amazon\\EC2-Windows\\Launch\\Module\\Ec2Launch.psd1"PS C:>Add-RoutesPS C:>Set-ActivationSettingsPS C:>slmgr /atoIf Windows still isn't activated, then proceed with step 2.2.    Microsoft KMS runs on port 1688 as TCP traffic. Be sure to add an exception to allow Microsoft KMS traffic on any firewall or security software that controls outbound connections from your instance.3.    Set your Windows KMS setup key. First, identify the correct Microsoft KMS client setup key for your operating system version. For more information, see Key Management Services (KMS) client activation and product keys on the Microsoft website. Then, run this command as administrator:slmgr.vbs /ipk <KMSSetupKey>4.    Set your Windows KMS machine IP address. Instances that originate from a VM import or an older EC2-Classic instance might not have the correct IP addresses for the Microsoft KMS servers. Run this command as administrator:slmgr.vbs /skms 169.254.169.250:16885.    To activate Windows, run this command as administrator:slmgr /ato6.    If the preceding step fails activation, then check the network communication from the instance to the Microsoft KMS server. To do this, perform telnet to the Microsoft KMS servers from the instance. Then, open PowerShell and enter these commands:Test-netconnection 169.254.169.250 -Port 1688Test-netconnection 169.254.169.251 -Port 1688Verify that the connection status output is TcpTestSuccessed=True. If the connection status output is False, proceed to step 7.7.    Verify that these registry keys have the correct Microsoft KMS values:HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\WindowsNT\\CurrentVersion\\SoftwareProtectionPlatformKeyManagementServiceName - 169.254.169.250 or 169.254.169.251KeyManagementServicePort - 16888.    Repeat the test in step 6. If the connection status output is still False, then verify that the Time sync on your EC2 instance. For more information, see Set the time for a Windows instance.Related informationEC2Config settings filesUnderstanding KMS (on the Microsoft website)Upgrading PV drivers on Windows instancesHow do I troubleshoot time issues with my EC2 Windows instance?Follow"


Question: How do I migrate my VPN from a virtual private gateway to a transit gateway?

I want to provide secure connectivity between my Amazon Virtual Private Cloud (Amazon VPC) and my virtual private network (VPN) using a transit gateway. How do I migrate my VPN from a virtual private gateway to a transit gateway?

Answer: "I want to provide secure connectivity between my Amazon Virtual Private Cloud (Amazon VPC) and my virtual private network (VPN) using a transit gateway. How do I migrate my VPN from a virtual private gateway to a transit gateway?ResolutionFollow these steps to complete the VPN migration from a virtual private gateway to a transit gateway.Note: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.Step 1: Create a transit gatewayFollow the steps to create a transit gateway.Note: Make sure to select Auto accept shared attachments to enable automatic acceptance of cross-account attachments.To create a transit gateway using the AWS CLI:aws ec2 create-transit-gatewayStep 2: Attach your VPCs to the transit gatewayFollow the steps to Attach your VPCs to the transit gateway.You must specify one subnet from each Availability Zone to be used by the transit gateway for routing traffic. Specifying one subnet from each Availability Zone enables traffic to reach resources in every subnet in that Availability Zone.Note: It's a best practice to create a separate subnet in each Availability Zone for the transit gateway elastic network interfaces.To attach a VPC to the transit gateway using the AWS CLI:aws ec2 create-transit-gateway-vpc-attachment--transit-gateway-id tgw-14324bbc412a43243--vpc-id vpc-2321314314--subnet-ids "subnet-12312312" "subnet-41343432"Step 3: Remove your static VPN routes (required for a static VPN connection migrating to a transit gateway)Follow the steps to remove the static VPN routes.To remove the static VPN routes using the AWS CLI:aws ec2 delete-vpn-connection-route     --vpn-connection-id vpn-12345678901234567     --destination-cidr-block 10.0.0.0/8Step 4: Migrate the existing Site-to-Site VPN to the transit gatewayTo migrate your VPN target from the virtual gateway to the new transit gateway:1.    Open the Amazon VPC console.2.    In the navigation pane, choose Site-to-Site VPN Connections.3.    Select the Site-to-Site VPN connection, choose Actions, and then choose Modify VPN Connection.4.    For Target Type, choose Transit Gateway.5.    Select your transit gateway from the target transit gateway ID dropdown list.6.    Choose Save.To migrate the Site-to-Site VPN target to the new transit gateway using the AWS CLI:aws ec2 modify-vpn-connection \    --vpn-connection-id vpn-12345678901234567 \    ----transit-gateway-id tgw-12345678910aa213Step 5: Update or create the VPC route table1.    Follow the steps to modify or add a route to a route table.2.    For existing routes, change the route Target from the virtual gateway ID to the new virtual gateway ID.3.    If no route exists, then create a new route with the transit gateway ID as the Target.Note: You must include VPC static routes even if the route table has propagation enabled.To create a new VPC route using the AWS CLI:aws ec2 create-route     --route-table-id rtb-4011223344aabb55c     --destination-cidr-block 10.0.0.0/8     --transit-gateway-id tgw-12345678910aa213To modify an existing route using the AWS CLI:aws ec2 replace-route     --route-table-id rtb-4011223344aabb55c     --destination-cidr-block 10.0.0.0/8     --transit-gateway-id tgw-12345678910aa213Step 6: Update the transit gateway route tablesFollow the steps to create or propagate transit gateway routes tables.To create the transit gateway route using the AWS CLI:aws ec2 create-transit-gateway-route \    --destination-cidr-block 10.0.0.0/8 \    --transit-gateway-route-table-id tgw-rtb-00abc11def22ghi33 \    --transit-gateway-attachment-id tgw-attach-123abc456def789ghNote: Migrating the VPN target causes a brief interruption of service until the Site-to-Site VPN modification completes.Related informationTransit gateway design best practicesMigrate from Transit VPC to AWS Transit GatewayFollow"


Question: How do I give internet access to a Lambda function that's connected to an Amazon VPC?

I want to grant internet access to my AWS Lambda function that's connected to an Amazon Virtual Private Cloud (Amazon VPC).

Answer: "I want to grant internet access to my AWS Lambda function that's connected to an Amazon Virtual Private Cloud (Amazon VPC).Short descriptionInternet access from a private subnet requires network address translation (NAT). To give internet access to an Amazon VPC-connected Lambda function, route its outbound traffic to a NAT gateway or NAT instance in a public subnet.For more information, see Connect to the internet using an internet gateway. For an example setup, see VPC with public and private subnets (NAT).Note: You can also use Amazon VPC endpoints to connect to supported AWS services from within an Amazon VPC without internet access.Resolution(Optional) Create a new Amazon VPC using the VPC Wizard in the AWS Management ConsoleNote: If you use the VPC wizard to create a new Amazon VPC, then skip ahead to the following section: Create a Lambda execution role for your VPC.1.    Open the VPC wizard in the AWS Management Console.2.    Choose VPC with Public and Private Subnets. The new Public subnet and Private subnet, including their associated internet gateway and NAT gateway, appear in the Amazon VPC console.Create a public subnet and one or more private subnets in your Amazon VPCFor instructions, see Create a subnet in your VPC to create each of your subnets.When you create the subnets, for Name tag, enter a name for each subnet that identifies it as either public or private. For example: Public subnet, Private lambda 1, and Private lambda 2.Note: It's a best practice to create more than one private subnet across different Availability Zones. This practice creates redundancy and allows the Lambda service to maintain high availability for your function.Create an internet gateway and attach it to your Amazon VPCFor instructions, see Create and attach an internet gateway.Create a NAT gatewayFor instructions, see Create a NAT gateway. When you create the NAT gateway, for Subnet, choose the subnet that you want to make public. (From the previous example: Public subnet.)Note: To test your NAT gateway setup, see Test the public NAT gateway.Create two custom route tables—one for your public subnet and one for your private subnetNote: When an Amazon VPC-connected Lambda function makes requests, it randomly selects an associated subnet. If the function uses a misconfigured subnet, then you get an error. To prevent random errors, make sure to use the same configuration for all subnets that your function uses.For instructions, see Create a custom route table. When you create the route tables, for Name tag, enter a name for each route table that helps you identify the subnet that it's associated with. For example: Public subnet and Private Lambda.For each route table, make sure that you complete the following steps:For the public subnet's route table1.    Associate the public subnet's route table (Public subnet) with the subnet that you want to make public.2.    Add a new route to the route table that includes the following configurations:For Destination, enter 0.0.0.0/0.For Target, choose Internet Gateway, and then choose the ID (igw-123example) of the internet gateway that you created. Choose Save routes.For the private subnet's route table1.    Associate the private subnet's route table (Private Lambda) with the private subnets.2.    Add a new route to the route table that includes the following configurations:For Destination, enter 0.0.0.0/0.For Target, choose NAT Gateway. Then, choose the ID of the NAT gateway (nat-123example) that you created.Important: If you're using a NAT instance, choose Network Interface instead. Choose Save routes.Note: Make sure that the routes to your NAT gateway are in an active status. If the NAT gateway is deleted and you didn't update the routes, they're in a blackhole status. For more information, see Delete a NAT gateway.Verify that your network ACL allows outbound requests from your Lambda function, and inbound traffic as neededThe default network access control list (network ACL) in your Amazon VPC allows all inbound and outbound traffic. If you change the network ACL rules, then make sure that you still allow outbound requests from your Lambda function.Also, make sure that your network ACL allows the following inbound traffic based on your VPC configuration:For private subnets that use a NAT gateway: allow inbound traffic on ephemeral ports 1024-65535.For private subnets that use a NAT instance: allow inbound traffic on the ephemeral ports used by your NAT instance operating system.Note: For more information, see Internetwork traffic privacy in Amazon VPC.Create a Lambda execution role for your VPC1.    Open the Roles page in the AWS Identity and Access Management (IAM) console.2.    Choose Create role. The Create role page opens.3.    On the Create role page, complete the following steps:For Select type of trusted entity, choose AWS service.For Common use cases, choose Lambda.Choose Next: Permissions.Under Attach permissions policies, search for AWSLambdaVPCAccessExecutionRole.Select the policy with that name. Then, choose Next: Tags.(Optional) Add tags for your use case.Choose Next: Review.For Role name, enter a name for your Lambda execution role. For example: lambda_vpc_basic_execution.(Optional) For Role description, enter a description of the role. Choose Create role.Attach the role to the Lambda function1.    Open the Functions page in the Lambda console.2.    Choose the name of the function that you want to connect to your Amazon VPC.3.    Choose the Configuration tab, and then choose Permissions.4.    In Execution role, choose Edit.5.    Choose the Existing role dropdown list, and then choose your role. For example: lambda_vpc_basic_execution.6.    Choose Save.For more information, see Lambda execution role and Creating an execution role in the IAM console.Configure your Lambda function to connect to your Amazon VPC1.    Open the Functions page in the Lambda console.2.    Choose the name of the function that you want to connect to your Amazon VPC.3.    Choose the Configuration tab.4.    Choose VPC from the left navigation bar, and then choose Edit. Then, enter the following fields:For Virtual Private Cloud (VPC), choose your VPC.For Subnets, select the private subnets that you created. Identify them by their subnet IDs (and names, if you named them).For Security groups, choose a security group.Note: The default security group allows all outbound internet traffic and is sufficient for most use cases. For more information, see Control traffic to resources using security groups.5.    Choose Save.Related informationConfiguring a Lambda function to access resources in a VPCTroubleshoot networking issues in LambdaHow do I troubleshoot Lambda function failures?Follow"


Question: Why can't I see CloudWatch Logs for an AWS DMS task?

Why can't I see Amazon CloudWatch Logs for an AWS Database Migration Service (AWS DMS) task?

Answer: "Why can't I see Amazon CloudWatch Logs for an AWS Database Migration Service (AWS DMS) task?Short descriptionTo view the CloudWatch Logs for your AWS DMS task, confirm the following:Amazon CloudWatch is enabled on the AWS DMS task.The dms-cloudwatch-logs-role AWS Identity and Access Management (IAM) role is created. The IAM role has the correct permissions policy, and has the correct trust relationship for AWS DMS to assume the role.ResolutionNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.First, enable CloudWatch logging for your task, if you haven't already. To enable CloudWatch logging, your task must be in a Stopped or Failed state.If CloudWatch logging is enabled for your task and you still can't view the logs, confirm that you have the required IAM role. Open the IAM console, and then choose Roles from the navigation pane. Confirm that dms-cloudwatch-logs-role is listed. If you created the task using the AWS Command Line Interface (AWS CLI) or the dms-cloudwatch-logs-role role wasn't created because the account doesn't have sufficient permissions, then create the role with the required policies using the AWS CLI or follow these steps:1.    Open the IAM console, and then choose Roles from the navigation pane.2.    Choose Create role.3.    Choose AWS service from Select type of trusted entity. Doing this allows the AWS service in the next step to perform actions on your behalf.4.    Choose DMS from Choose a use case. This creates the following trust relationship policy so that AWS DMS can assume the role:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "",      "Effect": "Allow",      "Principal": {           "Service": "dms.amazonaws.com"      },      "Action": "sts:AssumeRole"    }  ]}5.    Choose Next: Permissions.6.    Enter AmazonDMSCloudWatchLogsRole in the search field. Then, choose the policy to grant AWS DMS access to CloudWatch.7.    Choose Next: Tags.8.    Optionally, add metadata to the role by using tags as key-value pairs.9.    Choose Next: Review.10.    For Role name, enter dms-cloudwatch-logs-role.Note: The role name dms-cloudwatch-logs-role is case-sensitive, so be sure to enter the role name in lower case.11.    Role description is filled, and you can add or edit the description as needed.12.    Chose Create role.After the role is created, you can use CloudWatch Logs to monitor your AWS DMS task.Related informationMonitoring AWS DMS tasksFollow"


Question: "How do I assign a static hostname to an Amazon EC2 instance running RHEL 5 or 6, CentOS 5 or 6, or Amazon Linux?"

"I changed the hostname of my Amazon Elastic Compute Cloud (Amazon EC2) instance. However, when I reboot or stop and then start the instance, the hostname changes back. How do I make the hostname persist?"

Answer: "I changed the hostname of my Amazon Elastic Compute Cloud (Amazon EC2) instance. However, when I reboot or stop and then start the instance, the hostname changes back. How do I make the hostname persist?Short descriptionTo make a hostname persist when rebooting or stopping and starting your EC2 instance, add the hostname to the appropriate configuration files on the instance.Note: The following steps apply to Amazon Linux and RHEL 5 or 6, and CentOS 5 or 6. For instructions that apply to other distributions, see one of the following:Changing the system hostnameHow do I assign a static hostname to an Amazon EC2 instance running SLES?How do I assign a static hostname to an Amazon EC2 instance running Ubuntu Linux?How do I assign a static hostname to an Amazon EC2 instance running RHEL 7 or CentOS 7?Resolution1.    Open /etc/sysconfig/network in vim:sudo vim /etc/sysconfig/network2.    Change the value of the HOSTNAME parameter (replace persistent_hostname with your preferred hostname):HOSTNAME=persistent_hostname3.    Set NETWORKING to yes:NETWORKING=yes4.    Save and exit the vim editor.Note: After making this change, press SHIFT + : to open a new command entry box in the vim editor. Type wq, and then press Enter to save your changes and exit vim.5.    Open /etc/hosts in vim:sudo vim /etc/hosts6.    Change the entry beginning with 127.0.0.1 to the following, replacing persistent_hostname, localdomain, and localhost with your preferred hostname, local domain, and local host:127.0.0.1 persistent_hostname.localdomain localhost localhost.localdomain7.    Save and exit the vim editor.8.    To verify that you successfully changed the hostname, reboot your instance, and then run the hostname command:sudo reboothostnameThe command returns the new hostname.Related informationChanging the hostname of your Amazon Linux instanceFollow"


Question: How do I set up and connect to SMTP using Amazon SES?

I want to set up Simple Mail Transfer Protocol (SMTP) for Amazon Simple Email Service (Amazon SES). How do I set up and connect to SMTP using Amazon SES?

Answer: "I want to set up Simple Mail Transfer Protocol (SMTP) for Amazon Simple Email Service (Amazon SES). How do I set up and connect to SMTP using Amazon SES?ResolutionFollow these steps to set up SMTP with Amazon SES and then connect to the Amazon SES SMTP endpoint to send email:1.    Open the Amazon SES console.2.    From the navigation pane, choose Account dashboard.3.    Under Simple Mail Transfer Protocol (SMTP) settings, note the values for SMTP endpoints and Ports. Use the SMTP endpoint and ports to connect to SMTP. For example, if you're in the eu-west-1 AWS Region, note the following:SMTP endpoint: email-smtp.eu-west-1.amazonaws.comPort: 25, 465 or 5874.    Choose Create My SMTP Credentials. Then, proceed with the steps to generate your SMTP credentials.5.    Select the Amazon SES SMTP port that you'll send email from based on the connection method that you want to use (STARTTLS or TLS Wrapper).Important: Amazon Elastic Compute Cloud (Amazon EC2) restricts outbound traffic on port 25 for all EC2 instances by default. If you must use SMTP port 25, you can request to remove this restriction. Or, you can select a different port to send email.6.    Connect to the Amazon SES SMTP endpoint to test the connection over the port that you want to send email from. For example, you can run the telnet command:$ telnet email-smtp.eu-west-1.amazonaws.com 465Connected to email-smtp.eu-west-1.amazonaws.com.7.    After you confirm that the connection to the port is successful, you can start using your operating system's command line to start sending email using the Amazon SES SMTP interface.Follow"


Question: How do I resolve the "function not registered" syntax error in Amazon Athena?

"When I run a SELECT operation in Amazon Athena, I get a "function not registered" syntax error."

Answer: "When I run a SELECT operation in Amazon Athena, I get a "function not registered" syntax error.ResolutionIf you try to use a function that Athena doesn't support, then you receive an error that's similar to one of the following messages:"SYNTAX_ERROR: line 1:8: Function function_name not registered""FUNCTION_NOT_FOUND: line 1:8: Function 'function_name' not registered"For a list of functions that Athena supports, see Functions in Amazon Athena. Or, run a SHOW FUNCTIONS statement. See the following partial example of the output:    Function   Return Type     Argument Types   Function Type   Deterministic   Description1    abs        bigint          bigint           scalar          true            absolute value2    abs        decimal(p,s)    decimal(p,s)     scalar          true            absolute value3    abs        double          doubleIf Athena doesn’t support the function that you want to use, then write a user defined function (UDF) in Athena. UDFs allow you to create custom functions to process records or groups of records. A UDF accepts parameters, performs work, and then returns a result. For examples and more information about UDFs, see Querying with user defined functions.Related informationAmazon Athena UDF Connector (on GitHub)Connect Amazon Athena to your Apache Hive metastore and use user defined functionsFollow"


Question: "How can I restrict access to AWS resources based on the AWS Region, source IP address, or Amazon VPC?"

"I want to restrict access to AWS resources based on the AWS Region, source IP address, or Amazon Virtual Private Cloud (Amazon VPC)."

Answer: "I want to restrict access to AWS resources based on the AWS Region, source IP address, or Amazon Virtual Private Cloud (Amazon VPC).Short descriptionYou can use AWS Identity and Access Management (IAM) identity-based policies and Amazon Simple Storage Service (Amazon S3) bucket policies to deny or control access to AWS resources. You can deny or control access to AWS resources based on conditions such as the AWS Region, source IP, or VPC that the resource is being accessed from.ResolutionDeny access to AWS resources based on the requested AWS RegionCreate an identity-based policy with the IAM aws:RequestedRegion condition key that denies access to all actions outside the specified Regions.For an example IAM policy and more information, see Deny access based on the requested Region.Deny access to AWS resources based on the source IP addressCreate an identity-based policy with the IAM aws:SourceIp and aws:ViaAWSService condition keys that denies access to all actions outside the specified IP address range. Only public IP addresses or public IP ranges are supported.Note: The aws:SourceIp condition key is always included in the request, except for requests that uses an Amazon VPC endpoint.For an example IAM policy and more information, see Deny access based on the source IP address range.Control access from Amazon VPC with Amazon S3 bucket policiesCreate an Amazon S3 bucket policy with the IAM aws:SourceVpce condition key to restrict access to buckets from specific Amazon VPC endpoints. You can also create an Amazon S3 bucket policy with the IAM aws:SourceVpc condition key to restrict access to buckets from specific Amazon VPCs.For example IAM policies and more information, see Controlling access from VPC endpoints with bucket policies.Note: The aws:SourceVpc or aws:SourceVpce condition key is only included if the requester uses a VPC endpoint to make the request.Related informationAWS service endpointsAWS global condition context keysVPC endpointsFollow"


Question: How can I troubleshoot DNS resolution issues with my Route 53 private hosted zone?

How can I troubleshoot DNS resolution issues with my Amazon Route 53 private hosted zone?

Answer: "How can I troubleshoot DNS resolution issues with my Amazon Route 53 private hosted zone?Short descriptionTo troubleshoot DNS resolution issues with a Route 53 private hosted zone:Confirm that DNS support is enabled in the virtual private cloud (VPC).Confirm that the correct VPC ID is associated with the private hosted zone.(For custom DNS or Active Directory servers) Confirm that forwarding rules are configured for private hosted zone domains in the custom DNS servers towards the Amazon-provided DNS server (CIDR+2).Review custom settings in resolv.conf.Confirm that private hosted zones don't have overlapping namespaces.Confirm that there's no zone delegation configured in the private hosted zone.Confirm that the resource record's routing policy is supported in private hosted zones.Confirm that the Resolver rule and its inbound endpoint resolve to different VPCs.Confirm that the appropriate query type is configured.(For queries from on-premises to Route 53 Resolver) Confirm that the on-premises resolver sends a recursive request.Confirm that the correct rule priorities are configured for the Amazon-provided DNS.ResolutionNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.Confirm that DNS support is enabled in the VPCTo allow private hosted zone record resolution, DNS support must be enabled in your VPC. Be sure that DNSSupport and DNSHostnames are set to True in your VPC.Confirm that the correct VPC ID is associated with the private hosted zoneWhen you associate a private hosted zone with a VPC, Route 53 Resolver creates an auto-defined rule and associates it with the VPC. Resources in that VPC can resolve DNS records in the private hosted zone by querying the Resolver.Confirm that the correct VPC ID is associated with your private hosted zone. Also, be sure that you're querying the resource records of domain from within the same VPC.To get a list of VPCs associated with a hosted zone, use the following command in the AWS CLI:aws route53  list-hosted-zones-by-vpc --vpc-id <VPC-ID> --vpc-region <region-ID>To get a list of private hosted zones associated with specific VPCs, use the following command in the AWS CLI:aws route53 get-hosted-zone --id <id>Confirm that forwarding rules are configured for private hosted zone domains in custom DNS servers towards the Amazon-provided DNS server (CIDR+2)If you configured custom DNS servers or Active Directory (AD) servers in the DHCP options for DNS in your VPC:In the forwarding rule, confirm that you configured servers to forward DNS queries for the private domain to the IP address of the Amazon-provided DNS servers of your VPC. For example, if the CIDR range for your VPC is 172.31.0.0/16, then the IP address of the VPC DNS server is 172.31.0.2 (the VPC network range plus two).Confirm that the domain configured in the custom servers is different from your private hosted zone. If the domain is the same as your private hosted zone, the server is authoritative for that domain. The server won't contact the Amazon-provided DNS server for private hosted zone domains.Review custom settings in resolv.confIf you experience intermittent DNS resolution or responses, then review the configuration settings of your source instance resolv.conf.For example, let's say that you configured the Rotate option in resolv.conf to load balance DNS queries between the Amazon-provided DNS server and the public Google resolver server (8.8.8.8). The resolv.conf settings are:options rotate; generated by /usr/sbin/dhclient-scriptnameserver 8.8.8.8nameserver 172.31.0.2In your first query to the public Google resolver (8.8.8.8), you receive the expected NXdomain response. You receive this response because the resolver is trying to find the response in the public hosted zone instead of the private hosted zone.Private hosted Zone Record - resolvconf.local[ec2-user@ip-172-31-253-89 etc]$ curl -vks http://resolvconf.local* Rebuilt URL to: http://resolvconf.local/* Could not resolve host: resolvconf.local15:24:58.553320 IP ip-172-31-253-89.ap-southeast-2.compute.internal.40043 > dns.google.domain: 65053+ A? resolvconf.local. (34)15:24:58.554814 IP dns.google.domain > ip-172-31-253-89.ap-southeast-2.compute.internal.40043: 65053 NXDomain 0/1/0 (109)However, the second query resolves successfully. The second query is successful because it reaches the VPC DNS resolver associated to your private hosted zone.[ec2-user@ip-172-31-253-89 etc]$ curl -vks http://resolvconf.local* Rebuilt URL to: http://resolvconf.local/*   Trying 1.1.1.1...* TCP_NODELAY set* Connected to resolvconf.local (1.1.1.1) port 80 (#0)15:25:00.224761 IP ip-172-31-253-89.ap-southeast-2.compute.internal.51578 > 172.31.0.2.domain: 7806+ A? resolvconf.local. (34)15:25:00.226527 IP 172.31.0.2.domain > ip-172-31-253-89.ap-southeast-2.compute.internal.51578: 7806 1/0/0 A 1.1.1.1 (50)Confirm that private hosted zones don't have overlapping namespacesIf there are multiple zones with overlapping namespaces (such as example.com and test.example.com), then the Resolver routes traffic to the hosted zone based on the most specific match. If there's a matching zone but no record that matches the domain name and type in the request, then Resolver doesn't forward the request to another zone or a public DNS resolver. Instead, Resolver returns NXDOMAIN (non-existent domain) to the client.Confirm that you have the correct record configured in the most specific private hosted zone for successful DNS resolution.For example, let's say that you have two private hosted zones with records configured as follows:Private hosted zone nameRecord nameValuelocaloverlap.privatevpc.local60.1.1.1privatevpc.localoverlap.privatevpc.local50.1.1.1The request gets the following answer from the most specific matched private hosted zone:[ec2-user@IAD-BAS-INSTANCE ~]$ dig overlap.privatevpc.local +short50.1.1.1Confirm that there's no zone delegation configured in the private hosted zonePrivate hosted zones don't support zone delegation. If delegation is configured, the client gets the "Servfail" response code from the VPC resolver.Use the AWS CLI to confirm that zone delegation isn't configured in the private hosted zone. For example:Private hosted zone:abc.com Delegation NS record for: kc.abc.com Resource record: test.kc.abc.com[ec2-user@ip-172-31-0-8 ~]$ dig test.kc.abc.com;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63414;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0;; QUESTION SECTION:;test.kc.abc.com        IN      A;; Query time: 15 msec;; SERVER: 172.31.0.2#53(172.31.0.2);; WHEN: Fri Apr 16 15:57:37 2021;; MSG SIZE  rcvd: 48Confirm that the resource record's routing policy is supported in private hosted zonesConfirm that you configured a routing policy in your resource record that's supported by a private hosted zone. The supported routing policies are:Simple routingMultivalue answer routingFailover routingWeighted routingConfirm that the Resolver rule and its inbound endpoint resolve to different VPCsWhen the outbound endpoint in a Resolver rule points to an inbound endpoint that shares a VPC with the rule, the result is a loop. In this loop, the query is continually passed between the inbound and outbound endpoints.The forwarding rule can still be associated with other VPCs that are shared with other accounts using AWS Resource Access Manager (AWS RAM). Private hosted zones associated with the hub, or a central VPC, resolve from queries to inbound endpoints. A forwarding resolver rule won't change this resolution. For example:Hub VPC: VPC A - CIDR 172.31.0.0/16 Spoke VPC: VPC B - CIDR 172.32.0.0/16 Inbound IP address: 172.31.253.100 and 172.31.2.100 Target IP addresses in forwarding rule: 172.31.253.100 and 172.31.2.100 Rule associated with VPCs: VPC A and VPC B Client: 172-32-254-37ubuntu@ip-172-32-254-37:~$ dig overlap.privatevpc.local;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9007;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1;; QUESTION SECTION:;overlap.privatevpc.local. IN A;; Query time: 2941 msec;; SERVER: 172.32.0.2#53(172.32.0.2)In the previous output, the DNS request is continuously hopping between the outbound and inbound endpoints. The request checks the rule associated with VPC A and sends the query back to the outbound endpoint. After several attempts, the query times out and responds with a "Servfail" response code.To fix this issue and break the loop, remove the hub VPC association (VPC A) with the rule. Then, you get a successful response from the private hosted zone:ubuntu@ip-172-32-254-37:~$ dig overlap.privatevpc.local;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58606;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;overlap.privatevpc.local. IN A;; ANSWER SECTION:overlap.privatevpc.local. 0 IN A 50.1.1.1;; Query time: 5 msec;; SERVER: 172.32.0.2#53(172.32.0.2)Confirm that the on-premises resolver sends a recursive requestIf you use queries from on-premises to Route 53 Resolver, then with the Resolver inbound endpoint, you can forward DNS queries from resolvers on your network to a VPC resolver. This action lets you resolve domain names for AWS resources, such as records in a private hosted zone.In some cases, you might find that the private hosted zone isn't resolving successfully from the on-premises resolver. This behavior occurs because the on-premises resolver is sending an iterative query instead of a recursive request. The inbound endpoint is supporting recursive queries for successful DNS resolutions.You can verify the resolution type using a packet capture on the DNS resolver (on-premises). Then, review the DNS flags (recursion desired = 0). You can also test the resolution by sending an iterative request using +norecurse with the dig command, or set "norecurse" with nslookup as follows:Inbound endpoint IP address: 172.31.253.150 On-premises Resolver IP address: 10.0.4.210Failed iterative query to the inbound IP address:[ec2-user@IAD-BAS-INSTANCE ~]$ dig @172.31.253.150 overlap.privatevpc.local +norecurse; <<>> DiG 9.11.0rc1 <<>> @172.31.253.150 overlap.privatevpc.local +norecurse; (1 server found);; global options: +cmd;; connection timed out; no servers could be reachedSuccessful recursive query:[ec2-user@IAD-BAS-INSTANCE ~]$ dig @172.31.253.150 overlap.privatevpc.local;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19051;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0;; QUESTION SECTION:;overlap.privatevpc.local.      IN      A;; ANSWER SECTION:overlap.privatevpc.local. 0     IN      A       50.1.1.1;; Query time: 200 msec;; SERVER: 172.31.253.150#53(172.31.253.150)Confirm that the correct rule priorities are configured for the Amazon-provided DNSWhen the client instance sends a query to the resolver (AWS-provided DNS server), the resolver verifies the rules associated with the instance to determine where to route the request.In general, the most specific rule takes priority. If there's a "test.example.com" Resolver rule and a "longest.test.example.com" private hosted zone, then lookup for the "longest.test.example.com" domain matches the private hosted zone.If the rules are at the same domain level, the priority is:Resolver rulePrivate hosted zone ruleInternal ruleFor example, if there's a "test.example.com" Resolver rule and a "test.example.com" private hosted zone, then the Resolver rule takes priority. The query is forwarded to the servers or target IP addresses configured in the rule.Related informationWorking with private hosted zonesWhich Amazon VPC options do I need to enable to use my private hosted zone?Resolver endpointsFollow"


Question: How can I connect to an Amazon RDS DB instance from an Amazon SageMaker notebook instance that's in a different VPC?

I want to connect an Amazon SageMaker notebook instance to an Amazon Relational Database Service (Amazon RDS) DB instance that's in a different Virtual Private Cloud (VPC).

Answer: "I want to connect an Amazon SageMaker notebook instance to an Amazon Relational Database Service (Amazon RDS) DB instance that's in a different Virtual Private Cloud (VPC).Resolution1.    Create a VPC peering connection.2.    After the VPC peering connection is active, update the route tables. The RDS DB instance subnet and the SageMaker notebook instance subnet must have a route to each other. For example, for the following CIDR blocks:SageMaker VPC CIDR block: 192.168.0.0/16RDS DB instance VPC CIDR block: 10.0.0.0/24The Amazon RDS DB Instance subnet route table looks like this:DestinationTarget10.0.0.0/24local192.168.0.0/16Select the VPC peering connection from the dropdown listThe SageMaker notebook instance subnet route table looks like this:DestinationTarget10.0.0.0/24Select the VPC peering connection from the dropdown list192.168.0.0/16local3.    Confirm that both security groups are configured correctly. To allow traffic from the notebook instance to the RDS DB instance:On the notebook instance security group: Be sure that there's an outbound rule that allows traffic to the RDS DB instance.On the DB instance security group: Be sure that there's an inbound rule that allows the notebook instance's security group, VPC CIDR block, or subnet CIDR block.4.    To test the connection, run the following command in a terminal on the SageMaker notebook instance. Replace the following values in the example:mydatabase.c5y9vfc8igjj.ap-southeast-2.rds.amazonaws.com: the DB instance endpoint3306: the DB instance portcurl -v mydatabase.c5y9vfc8igjj.ap-southeast-2.rds.amazonaws.com:3306TroubleshootingIf the notebook instance has direct internet access activated, then the test command might fail (for example, "Connection timed out"). If this happens, run the following command to check the notebook instance's routing table at the operating system level:route -nWhen direct internet access is activated, the routing table looks similar to the following:Kernel IP routing tableDestination     Gateway         Genmask         Flags Metric Ref    Use Iface0.0.0.0         172.16.0.1      0.0.0.0         UG    0      0        0 eth010.0.32.0       0.0.0.0         255.255.224.0   U     0      0        0 eth1169.254.0.0     0.0.0.0         255.255.255.0   U     0      0        0 veth_def_agent169.254.169.254 0.0.0.0         255.255.255.255 UH    0      0        0 eth0172.16.0.0      0.0.0.0         255.255.224.0   U     0      0        0 eth0172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0172.18.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-5a785eca34a3192.168.0.0     0.0.0.0         255.255.128.0   U     0      0        0 eth2192.168.0.0     192.168.0.1     255.255.0.0     UG    0      0        0 eth2In this example, the DB instance's VPC CIDR block is 10.0.0.0/24. The operating system's routing table doesn't have a route to 10.0.0.0/24. Instead, traffic to the RDS VPC CIDR block uses the primary network interface (eth0), which handles public traffic. To resolve the connection issue, modify the routing table to use eth2, which is the notebook instance's VPC elastic network interface:1.    Note the SageMaker VPC router address. In this example, 192.168.0.0/16 (the notebook instance's VPC CIDR block) is routed to 192.168.0.1. This means that 192.168.0.1 is the VPC router address.2.    Add the route to the routing table in the notebook instance terminal. Replace these values in the example:10.0.0.0/24: the RDS DB instance's VPC CIDR block192.168.0.1: the SageMaker notebook instance's VPC router addresssudo ip route add 10.0.0.0/24 via 192.168.0.1 dev eth23.    Confirm that the new route is in the routing table:Kernel IP routing tableDestination     Gateway         Genmask         Flags Metric Ref    Use Iface0.0.0.0         172.16.0.1      0.0.0.0         UG    0      0        0 eth010.0.0.0        192.168.0.1     255.255.255.0   UG    0      0        0 eth210.0.32.0       0.0.0.0         255.255.224.0   U     0      0        0 eth1169.254.0.0     0.0.0.0         255.255.255.0   U     0      0        0 veth_def_agent169.254.169.254 0.0.0.0         255.255.255.255 UH    0      0        0 eth0172.16.0.0      0.0.0.0         255.255.224.0   U     0      0        0 eth0172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0172.18.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-5a785eca34a3192.168.0.0     0.0.0.0         255.255.128.0   U     0      0        0 eth2192.168.0.0     192.168.0.1     255.255.0.0     UG    0      0        0 eth24.    Test the connection again.Note: Changes to the operating system routing table don't persist between notebook instance sessions. This means that you lose the changes when you stop and start the SageMaker notebook instance. To mitigate this, use a lifecycle configuration to add the route every time that you start the notebook instance.Related informationConnect a notebook instance to resources in a VPCConnect to SageMaker through a VPC interface endpointFollow"


Question: How do I resolve "Session expired" errors from Amazon Connect?

"I get a "Session expired" error message when I try to open the Amazon Connect Contact Control Panel (CCP). Why am I receiving this error, and how do I resolve the issue?"

Answer: "I get a "Session expired" error message when I try to open the Amazon Connect Contact Control Panel (CCP). Why am I receiving this error, and how do I resolve the issue?Short descriptionIf you're using SAML 2.0 with Amazon Connect and your session expires, Amazon Connect returns the following error:Session expiredYour session has expired. Please log in again to continue. Sessions expire after 12 hours.To resolve the error, you must log out of your identity provider (IdP), and then log back in to Amazon Connect through your IdP.Note: Amazon Connect sessions expire 12 hours after a user logs in. After 12 hours, users are automatically logged out. For more information, see SAML user logging in and session duration.Resolution1.    Log out of your IdP.2.    Log in to Amazon Connect through your IdP.Important: When you use SAML in Amazon Connect, you can't use the AWS Management Console link to log in. You must log in through your IdP.Your new Amazon Connect session will be active for 12 hours, unless you log out before then.Follow"


Question: How can I resolve the AWS KMS key policy error "Policy contains a statement with one or more invalid principals"?

"I tried to modify my AWS Key Management Service (AWS KMS) key policy, and I received an error in the AWS Management Console similar to the following:"PutKeyPolicy request failedMalformedPolicyDocumentException - Policy contains a statement with one or more invalid principals"The AWS KMS key policy doesn't contain the Amazon Resource Name (ARN), and it contains a principal with a unique ID that is similar to AIDACKCEVSQ6C2EXAMPLE."

Answer: "I tried to modify my AWS Key Management Service (AWS KMS) key policy, and I received an error in the AWS Management Console similar to the following:"PutKeyPolicy request failedMalformedPolicyDocumentException - Policy contains a statement with one or more invalid principals"The AWS KMS key policy doesn't contain the Amazon Resource Name (ARN), and it contains a principal with a unique ID that is similar to AIDACKCEVSQ6C2EXAMPLE.Short descriptionThe AWS KMS API call PutKeyPolicy request fails when the request was rejected because the specified key policy isn't syntactically or semantically correct.ResolutionJSON syntaxConfirm that the JSON policy document resource type is valid. To troubleshoot JSON syntax errors, paste the JSON policy document into a JSON Beautifier to check the formatting. Remove any unnecessary characters and add any missing characters. Check for duplicate JSON policy elements and duplicate SID values and remove them.Invalid principalsCheck the principal element in the JSON policy and make sure that the AWS Identity and Access Management (IAM) entity exists. Ensure that the IAM identity is correctly specified with a valid ARN.Note: You can't use a wildcard in the portion of the ARN that specifies the resource type.When you create IAM identities, you give them friendly names, such as Bob or Developers. For security purposes, these IAM entities are also assigned a unique ID, such as AIDACKCEVSQ6C2EXAMPLE.For example, you have an IAM user named Alice specified in an AWS KMS key policy. Then, Alice leaves the company. After that, a new user named Alice is hired, and an IAM user is created with the same name. Unique IDs assure that the new Alice can't inherit permissions that were granted to the old Alice.Remove the orphaned unique IDs from the key policy. For more information, see Using key policies in AWS KMS.Note: If the AWS KMS key policy has permissions to another account or principal, the key policy is in effect only in the AWS Region that contains the KMS key. For more information, see Overview of key policies.Invalid AWS servicesIf an AWS service is listed as the principal, then make sure that the service is supported by AWS KMS. The principal should be the IAM entity and kms:ViaService should be used for the AWS services making the requests on behalf of the IAM entity.Check if the AWS service makes direct calls to AWS KMS. Not all AWS services make calls directly to AWS KMS such as Amazon Elastic Compute Cloud (Amazon EC2). Instead, AWS services such as Amazon EC2 make calls on behalf of a principal in the AWS account. AWS services that make direct calls to AWS KMS such as Amazon Simple Notification Service (Amazon SNS) must have the service principal in the principal element.For more information, see Services that support the kms:ViaService condition key.Opt-in AWS RegionAWS KMS keys shared with an AWS account that hasn't opted-in to the AWS Region where the key is located within the recipient account are invalid for that Region.Make sure that the AWS Region is enabled in the recipient account or share another AWS KMS key in a Region that is enabled in the AWS account and recipient account. For more information, see Managing AWS Regions.Related informationChanging an AWS KMS key policyFollow"


Question: How do I create an SFTP user on my Lightsail instance?

I want to create an SFTP user on my Amazon Lightsail instance. How can I do this?

Answer: "I want to create an SFTP user on my Amazon Lightsail instance. How can I do this?ResolutionNote: The following steps create an SFTP user who has access to chroot environment (chroot jail) with no SSH access. The SFTP user can't access the directories outside the chroot environment or directory. So, the chroot directory becomes the root directory for the user.1.    Create a group for the SFTP users. The group helps manage many different SFTP users. In this example, the group name is sftp_group. You can change the name to a group name of your choice.sudo groupadd sftp_group2.    Create a user on the instance with a home directory. This user performs SFTP tasks only and doesn't have an SSH login shell. In the following example, replace sftp_user with a user name of your choice.sudo useradd -g sftp_group -m -d  /home/sftp_user -s /sbin/nologin sftp_user3.    The user can authenticate in different ways when connecting to the server through SFTP. The following example uses a password and SSH key-based authentication.Password authenticationTo require password authentication, create a password using the following command:sudo passwd sftp_userSSH key-based authenticationIf you're using SSH key-based authentication, you need to create the SSH files for the user and then add the public key to the files. To do this:In the home directory of the user, create a .ssh folder and an authorized_keys file:sudo mkdir /home/sftp_user/.sshsudo touch /home/sftp_user/.ssh/authorized_keysAdd the SSH public key you want to use to the /home/sftp_user/.ssh/authorized_keys file. For more information, see Set up SSH for your Linux/Unix-based Lightsail instances.Run the following commands to change the ownership and permissions of the home directory of the user:sudo chown sftp_user:sftp_group /home/sftp_user/.ssh -Rsudo chown root:sftp_group /home/sftp_user/sudo chmod 755 /home/sftp_user/ sudo chmod 700 /home/sftp_user/.ssh/sudo chmod 600 /home/sftp_user/.ssh/authorized_keysThe preceding example uses permission 755 on the /home/sftp_user directory and changes ownership to the root user. This is because the directory is going to be used as a chroot directory. Keep in mind that all components of the pathname must be root-owned directories that aren't writable by any other user or group.4.    Edit the /etc/ssh/sshd_config file by doing the following:Modify the Subsystem sftp line by commenting out the Subsystem sftp /usr/libexec/openssh/sftp-server line:# Subsystem sftp /usr/libexec/openssh/sftp-serverReplace the preceding line with:Subsystem sftp internal-sftpAdd directives to limit the SFTP users access. These directives must be added at the bottom of the file:Match Group sftp_groupChrootDirectory /home/%uForceCommand internal-sftpIn the preceding example, the ChrootDirectory directive is used to specify the root directory for the SFTP users (chroot jail). Match block the user belonging to the sftp_group uses the path /home/%u as their root directory. The characters %u represents the user. You can change the root directory for your user.The ForceCommand internal-sftp directive forces usage of an in-process SFTP server.If you use password authentication, find the directive PasswordAuthentication in the /etc/ssh/sshd_config file and make sure that it is set to yes.5.    Create the chroot directories to be used by the user. Replace the directory name sftp_user, and uploads with your preferred names.sudo mkdir /home/sftp_user/uploadsModify the ownership of the files:sudo chown sftp_user:sftp_group /home/sftp_user/uploads6.    Verify that the directory permissions are as shown in the following example:ls -ld /homedrwxr-xr-x 3 root root 23 Oct  6 15:17 /homels -ld /home/sftp_userdrwxr-xr-x 3 root sftp_group 21 Oct  6 15:17 /home/sftp_userls -ld /home/sftp_user/uploads/drwxr-xr-x 2 sftp_user sftp_group 6 Oct  6 15:17 /home/sftp_user/uploads/7.    Restart the sshd service:sudo systemctl restart sshd8.    Connect to the instance using sftp:Password authentication# sftp sftp_user@example.comsftp_user@example.com's password:SSH key-based authentication# sftp -i key.pem sftp_user@example.comFollow"


Question: How do I pass data through an API Gateway REST API to a backend Lambda function or HTTP endpoint?

I want my Amazon API Gateway REST API to pass data to a backend AWS Lambda function and an HTTP endpoint. How can I do that?

Answer: "I want my Amazon API Gateway REST API to pass data to a backend AWS Lambda function and an HTTP endpoint. How can I do that?Short descriptionTo configure a REST API to pass data to a backend Lambda function, use a Lambda custom integration.To pass query string parameters to an HTTP endpoint, use an HTTP custom integration.Important: Make sure that the input data is supplied as the integration request payload. It’s a best practice to use a mapping template to supply the payload. For more information, see Map request and response payloads between method and integration.ResolutionCreate a Lambda function to handle custom headers from your API Gateway API1.    Open the Lambda console.2.    Choose Create function. The Create function page opens with the Author from scratch option selected.3.    In the Basic information pane, do the following: For Function name, enter a name that describes your function's purpose. For example: MapTemplate. For Runtime, choose Python 3.9.4.    For Permissions, expand Change default execution role.5.    Choose Use an existing role. A dropdown list of existing roles appears.6.    For Existing role, choose the Lambda execution role that you created earlier.7.    Choose Create function.8.    From the Code tab, in Code source, replace the code in lambda_function.py with the following:import jsondef lambda_handler(event, context):    print(event)    return {        'statusCode': 200,        'body': json.dumps(event) # returning the data sent to backend lambda function as API response.    }9.    Choose Deploy.For more information, see Building Lambda functions with Python.Pass data to the backend Lambda function or HTTP endpoint1.    Open the API Gateway console.2.    Choose Create API.-or-(If this is your first time using API Gateway) A page that introduces you to the features of the service appears. In REST API, choose Build. When the Create Example API popup appears, choose OK.3.    For Choose an API type, in the REST API pane, choose Build.4.    In Create new API, choose New API.5.    In Settings , do the following: For API name , enter a name that describes your API's purpose. For example: MappingTemplateTutorial. (Optional) For Description , enter a short description your API's purpose. For example, Send Data to Backend Lambda function/HTTP endpoint. For Endpoint Type , choose Regional.6.    Choose Create API.Configure your API's resources, integration point, and body mapping template1.    In the API Gateway console, choose the name of the API that you created in the previous step. Your API's Resources page opens.2.    On the Resources page, choose Actions. Then, choose Create Resource.3.    In the New Child Resource pane, for Configure as proxy resource , select the check mark icon , and then choose Create Resource.4.    On the /{proxy+} - ANY - Setup page, do the following:For Integration type, choose Lambda Function Proxy.For Lambda Region, choose the AWS Region that hosts your function.For Lambda Function, enter the function's name MappingTemplateTutorial.Choose Save. An Add Permission to Lambda Function popup appears, choose OK.7.    On the / {proxy+} - ANY - Method Execution page, choose Integration Request.8.    On the / {proxy+} - ANY  - Integration Request page, do the following:Uncheck the Use Lambda Proxy integration icon box. A Switch to Lambda integration popup appears.In the popup, choose OK. An Add Permission to Lambda Function popup appears. In the popup, choose OKExpand Mapping Templates.For Request body passthrough, choose When there are no templates defined (recommended).Choose Add mapping template. For Content-Type, enter application/json. Then, choose the check mark icon.9.    Choose the Generate template dropdown list, and then choose Method Request passthrough.10.    In the mapping template editor, enter the following:##  See http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html#set($allParams = $input.params()){"method" : "$context.httpMethod", ## API method"authcontext" : "$context.authorizer.stringkey", ## Optional output from Lambda Authorizers## passthrough body"body-json" : $input.json('$'),## passthrough headers, querystrings and path parameters"params" : {#foreach($type in $allParams.keySet())    #set($params = $allParams.get($type))"$type" : {    #foreach($paramName in $params.keySet())    "$paramName" : "$util.escapeJavaScript($params.get($paramName))"        #if($foreach.hasNext),#end    #end}    #if($foreach.hasNext),#end#end}}11.    Choose Save.12.    Choose Method Execution to come back to  / {proxy+} - ANY - Method Execution page.13.    Choose Method Response to setup valid method response.14.    On /{proxy+} - ANY - Method Response page, Choose Add Response.15.    For HTTP status code, enter 200. Then, choose the check mark icon.16.    Choose Actions to Deploy API to a stage.Deploy your API to a new stage1.    Follow the instructions in Deploy a REST API to a stage. For more information, see Setting up a stage using the API Gateway console.2.    In the Stage Editor pane, copy the Invoke URL to your clipboard.REST API Invoke URL examplehttps://1a2bc3d456.execute-api.us-east-1.amazonaws.com/stageTest your setupTo confirm that all data is being passed to backend Lambda function or HTTP endpoint by your API, run the following curl command:Important: Replace https://restApiId.execute-api.region.amazonaws.com/stageName with your API's invoke URL.curl -i --location --request POST 'https://1a2bc3d456.execute-api.us-east-1.amazonaws.com/stage/path1/path2?query1=querystring1&query2=querystring2' --header 'header1: value1' --header 'header2: value2' --header 'Content-Type: application/json' --data-raw '{"keybody":"valuebody"}'The command output includes all data received by the backend Lambda function to the client. You can update the output message for your environment.Note: To install curl on Windows, see Downloads on the Git website. For more information about curl, see the curl project website.Related informationTutorial: Build an API Gateway REST API with Lambda non-proxy integrationSetting up data transformations for REST APIsHow do I pass custom headers through API Gateway to a Lambda function using custom Lambda integration?Follow"


Question: How do I troubleshoot connection problems between an AWS VPN endpoint and a policy-based VPN?

"I'm using a policy-based virtual private network (VPN) to connect to my AWS Virtual Private Network (AWS VPN) endpoint in Amazon Virtual Private Cloud (Amazon VPC). I'm experiencing problems, such as packet loss, intermittent or no connectivity, and general network instability, and want to troubleshoot these issues."

Answer: "I'm using a policy-based virtual private network (VPN) to connect to my AWS Virtual Private Network (AWS VPN) endpoint in Amazon Virtual Private Cloud (Amazon VPC). I'm experiencing problems, such as packet loss, intermittent or no connectivity, and general network instability, and want to troubleshoot these issues.Short descriptionWhen you use a policy-based VPN connection to connect to an AWS VPN endpoint, AWS limits the number of security associations to a single pair. The single pair includes one inbound and one outbound security association.Policy-based VPNs with more than one pair of security associations will drop existing connections when new connections with different security associations initiate. This behavior indicates that a new VPN connection has interrupted an existing one.ResolutionLimit the number of encryption domains (networks) with access to your VPC. If you have more than one encryption domain behind your VPN's customer gateway, then configure them to use a single security association. To check if multiple security associations exist for your customer gateway, see the Troubleshooting your customer gateway device.Configure your customer gateway to allow any network behind the customer gateway (0.0.0.0/0) with a destination of your VPC Classless Inter-Domain Routing (CIDR) to pass through the VPN tunnel. This configuration uses a single security association, which improves tunnel stability. This configuration also allows networks that aren't defined in the policy to access the VPC.If possible, implement a traffic filter on your customer gateway to block unwanted traffic to your VPC. Configure security groups to specify what traffic can reach your instances. Also configure network access control lists (network ACLs) to block unwanted traffic to subnets.Related informationWhy is IKE (phase 1 of my VPN tunnel) failing in Amazon VPC?Why is IPsec/Phase 2 for AWS Site-to-Site VPN failing to establish a connection?Follow"


Question: How can I improve the speed of an AWS DMS task that has LOB data?

My AWS Database Migration Service (AWS DMS) migration task is slow. How can I improve the speed of an AWS DMS task that has large object (LOB) data?

Answer: "My AWS Database Migration Service (AWS DMS) migration task is slow. How can I improve the speed of an AWS DMS task that has large object (LOB) data?Short DescriptionAWS DMS offers the following options when migrating LOB data:Full LOB modeLimited LOB modeInline LOB modeResolutionFull LOB modeWhen using Full LOB mode, AWS DMS migrates LOBs regardless of their size. Because AWS DMS doesn't know the size of the LOB data that needs to be migrated, AWS DMS migrates LOBs one at a time. This can slow down your task. Although the migration is slower, the advantage is that data isn't truncated. To improve the performance of a task that uses Full LOB mode with multiple tables, identify the size of the largest LOB in your database. Then, you can use Limited LOB mode if the size of the largest LOB size isn't more than a few megabytes.If you have LOBs that are larger than a few megabytes, then you can create a separate AWS DMS task with Full LOB mode. It's a best practice to create the separate task on a new replication instance to migrate these tables alone.Limited LOB modeWhen using Limited LOB mode, you specify the maximum size of LOB column data. This allows AWS DMS to pre-allocate resources and apply the LOBs in bulk. If the size of the LOB columns exceeds the size that you specified in the task, then AWS DMS truncates the data. AWS DMS then sends warnings to the AWS DMS log file. Using Limited LOB mode improves performance, but before you run the task, you must identify the maximum LOB size of the data on the source. Then, you must specify the Max LOB size parameter when using Limited LOB mode. It's a best practice to be sure that you have enough memory allocated to the replication instance to handle the task.Inline LOB modeWhen using Inline LOB mode, you can migrate LOBs without truncating data or slowing your task performance, by replicating both small and large LOBs. First, specify a value for the InlineLobMaxSize parameter, which is available only when Full LOB mode is set to true. The AWS DMS task transfers the small LOBs inline, which is more efficient. Then, AWS DMS migrates LOBs that are larger than the specified size in Full LOB mode by performing a lookup from the source table. However, Inline LOB mode works only during the full load phase.Important: You must set the InlineLobMaxSize when you specify the task settings for your task. {  "TargetMetadata": {    "TargetSchema": "abc",    "SupportLobs": true,    "FullLobMode": true,    "LobChunkSize": 64,    "LimitedSizeLobMode": false,    "LobMaxSize": 0,    "InlineLobMaxSize": 32,    "LoadMaxFileSize": 0,    "ParallelLoadThreads": 0,    "ParallelLoadBufferSize": 0,    "BatchApplyEnabled": false,    "TaskRecoveryTableEnabled": false,    "ParallelLoadQueuesPerThread": 0,    "ParallelApplyThreads": 0,    "ParallelApplyBufferSize": 0,    "ParallelApplyQueuesPerThread": 0  }Related InformationMigrating Large Binary Objects (LOBs)Target Metadata Task SettingsBest Practices for AWS Database Migration ServiceFollow"


Question: How do I troubleshoot connection errors when I set up input data for an Amazon SageMaker Ground Truth labeling job?

I want to troubleshoot connection errors when I try to set up input data for an Amazon SageMaker Ground Truth labeling job.

Answer: "I want to troubleshoot connection errors when I try to set up input data for an Amazon SageMaker Ground Truth labeling job.ResolutionWhen you have connection issues with SageMaker Ground Truth, you might get an error similar to the following:Connection error: There was an issue with your input data setup. Ground Truth could not setup a connection with your dataset in S3. Please check your input data setup and try again, or use the manual data setup option. Network Failure Request id: <request_id>This error usually occurs because your AWS Identity and Access Management (IAM) role doesn't have the permissions that are required for setting up the input data.To troubleshoot this error, be sure that the role that you're using has the following policies attached:AmazonSageMakerFullAccessAmazon Simple Storage Service (Amazon S3) read and write accessIssues with SageMaker accessIf the IAM role that you're using doesn't have the AmazonSageMakerFullAccess policy attached, then attach the following Ground Truth actions to the policy:groundtruthlabeling:DescribeConsoleJobgroundtruthlabeling:ListDatasetObjectsgroundtruthlabeling:RunFilterOrSampleManifestJobgroundtruthlabeling:RunGenerateManifestByCrawlingJobFor more information, see Permissions.Issues with Amazon S3 accessBe sure that the IAM role includes the required permissions to access the input data files in the Amazon S3 bucket. For more information, see S3: Allows read and write access to objects in an S3 bucket.Issues with cross-account accessIf the data that you are setting up is in another account, then be sure that the execution role account has cross-account access to the S3 objects. For more information, see How can I provide cross-account access to objects that are in Amazon S3 buckets?Issues with service control policiesBe sure that the service control policies applied at the organization level don't restrict actions on the member account. For example, even if the execution role has the required permissions attached, an explicit DENY on all groundtruthlabeling actions restricts the connection and results in a connection error. For more information, see SCP effects on permissions.Follow"


Question: How can I use BGP communities to influence the preferred routing path on Direct Connect links from AWS to my network?

I want to use Border Gateway Protocol (BGP) communities to influence the preferred routing path on AWS Direct Connect links from AWS to my network.

Answer: "I want to use Border Gateway Protocol (BGP) communities to influence the preferred routing path on AWS Direct Connect links from AWS to my network.Short descriptionTo configure private and transit virtual interfaces to prioritize which interface AWS uses to route traffic to your network, use the AS_PATH attribute. Direct Connect also supports local preference BGP community tags to control the route preference of traffic on private and transit virtual interfaces.Note: Local preference BGP community tags are evaluated before the AS_PATH attribute.ResolutionCommunity tagsDirect Connect supports the following local preference BGP communities:7224:7100 Low preference7224:7200 Medium preference7224:7300 High preferenceDirect Connect evaluates local preference BGP community tags from lowest to highest preference. For each prefix that you advertise over a BGP session, you can apply a community tag to indicate the associated path's priority for returning traffic. Similarly, when you advertise from on-premises to AWS, you can prepend additional AS_PATH attributes to the prefixes. Direct Connect prioritizes the path with the fewest AS_PATH attributes for returning traffic.The following scenario is an example use case:You have two virtual interfaces A and B and advertising prefixes 10.10.10.0/24 and 10.20.20.0/24 to AWS.You want virtual interface A to be preferred for traffic to network 10.10.10.0/24.You want virtual interface B to be preferred for traffic to network 10.20.20.0/24.In this case, you can use local preference community tags:Apply higher preference tag 7224:7300 to prefix 10.10.10.0/24 on the BGP session in virtual interface A.Apply higher preference tag 7224:7300 to prefix 10.20.20.0/24 on the BGP session in virtual interface B.Note:For private virtual interfaces, if you don't use BGP community tags to specify local preference, then the outbound routing behavior defaults to an AWS Region. In this case, the behavior is based on the Direct Connect locations' relative distance to the originating Region. If the relative distance costs aren't equal, then Autonomous System (AS) prepending can't influence routing behavior. Direct Connect evaluates the lowest distance relative cost before AS_PATH prepending.To load balance traffic across multiple AWS Direct Connect connections, apply the same community tag across the prefixes for the connections.Configuring AS_PATH and BGP community attributesYou must configure AS_PATH prepending and BGP community tags on an on-premises router. Advertise the prefixes from this router to the Direct Connect router. Because you can use any routing device for this task, you must refer to a configuration that's specific to your vendor's router. See the following external documentation for vendors that are commonly used for on-premises routers:Configure AS_PATH prepending on Juniper.Configure AS_PATH prepending on PaloAlto.Configure AS_PATH prepending on Cisco.Configure your BGP community on Juniper.Configure your BGP community on PaloAlto.Configure your BGP community on Cisco.The following example configuration prepends an AS_PATH for prefix 10.0.0.0/8 on a Cisco router and advertise to AWS:Router(config)#access-list 10 permit 10.0.0.0 0.255.255.255Router(config)#route-map cisco permit 10Router(config-route-map)#match ip address 10Router(config-route-map)#set as-path prepend 650014 650014Router(config-route-map)#exitRouter(config)#route-map cisco permit 20Router(config-route-map)#exitRouter(config)#router bgp LOCAL\_ASRouter(config-router)#neighbor NEIGHBOR\_IP route-map cisco outRouter(config-router)#endThe following example configuration advertises prefix 10.0.0.0/8 with the BGP community tag 7224:7300 from a Cisco router to AWS:Router(config)#access-list 10 permit 10.0.0.0 0.255.255.255  Router(config)#route-map cisco permit 10  Router(config-route-map)#match ip address 10  Router(config-route-map)#set community 7224:7300  Router(config-route-map)#exit  Router(config)#route-map cisco permit 20  Router(config-route-map)#exit  Router(config)#router bgp LOCAL\_AS  Router(config-router)#neighbor NEIGHBOR\_IP send-community  Router(config-router)#neighbor NEIGHBOR\_IP route-map cisco out  Router(config-router)#endNote: In these examples, replace LOCAL_AS and NEIGHBOR_IP with your values.Related informationPublic virtual interface BGP communitiesRouting policies and BGP communitiesHow can I use BGP communities to control the routes advertised and received over the AWS public virtual interface with Direct Connect?Follow"


Question: How can I troubleshoot access denied errors when invoking API Gateway APIs with a resource based policy?

I'm getting an access denied error when invoking an Amazon API Gateway API operation with a resource policy.

Answer: "I'm getting an access denied error when invoking an Amazon API Gateway API operation with a resource policy.ResolutionFollow these troubleshooting steps for your public or private API Gateway API operation.Public API operations1.    Check if the API operation has a resource policy that allows or blocks the request based on IP addresses. If you don't have access logging set up, then set up access logging for API Gateway. Access logs contain the source IP addresses for your API operations. Make sure that the IP address isn't in the deny list. The IP address or the CIDR range must explicitly allow access in the resource policy.Example resource policy that allows only three IP addresses:{    "Version": "2012-10-17",    "Statement": [        {            "Effect": "Allow",            "Principal": "*",            "Action": "execute-api:Invoke",            "Resource": "arn:aws:execute-api:<region>:<account_number>:<api_id>/*"        },        {            "Effect": "Deny",            "Principal": "*",            "Action": "execute-api:Invoke",            "Resource": "arn:aws:execute-api:<region>:<account_number>:<api_id>/*",            "Condition": {                "NotIpAddress": {                    "aws:SourceIp": [                        "52.36.146.106",                        "34.216.36.206/32",                        "205.251.233.179/32"                    ]                }            }        }    ]}Example resource policy that blocks two IP addresses:{    "Version": "2012-10-17",    "Statement": [        {            "Effect": "Allow",            "Principal": "*",            "Action": "execute-api:Invoke",            "Resource": [                "arn:aws:execute-api:<region>:<account_number>:<api_id>/*"            ]        },        {            "Effect": "Deny",            "Principal": "*",            "Action": "execute-api:Invoke",            "Resource": [               "arn:aws:execute-api:<region>:<account_number>:<api_id>/*"            ],            "Condition" : {                "IpAddress": {                    "aws:SourceIp": ["52.36.146.106", "34.216.36.206/32" ]                }            }        }    ]}2.    The HTTP method (GET, POST) and the API Gateway resource (/,/foo,/foo/bar) for the API request must explicitly allow access. Check the resource policy attribute similar to the following:"Resource": [               "arn:aws:execute-api:<region>:<account_number>:<api_id>/<stage>/<http_method>/<resource_path_specifier>/*"            ],3.    Check if the resource policy uses other types of authentication methods or authorizers. The API Gateway evaluation of the resource policy is affected by your authentication type. Example authentication types include an AWS Lambda authorizer or Amazon Cognito authentication. Make sure that the resource policy is configured correctly for the authentication type defined for your API.4.    Make sure that you redeploy your API request for all changes to take effect. To redeploy your API request, repeat the steps to deploy a REST API to a stage.5.    If you are using an example API Gateway resource policy, make sure that you have configured all variables for your environment.6.    If your resource policy only allows access to within your Amazon Virtual Private Cloud (Amazon VPC) IP addresses, then do one of the following:Allow the router IP address and NAT Gateway IP address (public IP address) access in your resource policy.-or-Change the public API endpoint to a private API endpoint.Private API operations1.    If the resource policy has an Amazon VPC endpoint, then check the policy for the condition key. If the resource policy uses the condition key aws:SourceVpce, then its value must be the Amazon VPC endpoint ID, not the VPC ID. If the resource policy uses the condition key aws:SourceVpc, then its value must be the Amazon VPC ID, not the VPC endpoint ID.To check the endpoint type, open the Amazon VPC console, choose Endpoints, and then choose your endpoint.2.    Make sure that you redeploy your API request for all changes to take effect. To redeploy your API request, repeat the steps to deploy a REST API to a stage.3.    If you're using an example API Gateway resource policy, then make sure that you configure all variables for your environment.4.    The HTTP method (GET, POST) and the API Gateway resource (/,/foo,/foo/bar) for the API request must explicitly allow access. Check the resource policy attribute similar to the following:"Resource": [               "arn:aws:execute-api:<region>:<account_number>:<api_id>/<stage>/<http_method>/<resource_path_specifier>/*"            ],5.    Check if the resource policy uses other types of authentication methods or authorizers. The API Gateway evaluation of the resource policy is affected by your authentication type. Example authentication types include an AWS Lambda authorizer or Amazon Cognito authentication. Make sure that the resource policy is configured correctly for the authentication type defined for your API.Follow"


Question: How do troubleshoot issues when I integrate Amazon RDS for Oracle with Amazon S3?

I want to troubleshoot issues and errors when I integrate Amazon Relational Database Service (Amazon RDS) for Oracle with Amazon Simple Storage Service (Amazon S3).

Answer: "I want to troubleshoot issues and errors when I integrate Amazon Relational Database Service (Amazon RDS) for Oracle with Amazon Simple Storage Service (Amazon S3).Short descriptionWhen you transfer files between an Amazon RDS for Oracle DB instance and an Amazon S3 bucket, be sure of the following:The DB instance and the S3 bucket are in the same AWS Region.The DB instance has the required access to the S3 bucket.The DB instance is associated with an option group that includes the S3_INTEGRATION option.You're uploading files only from the Oracle directory object. This directory might be a user-created directory or a DATA_PUMP_DIR directory.If you're using a user-created directory, then the user performing the upload and download must have the required read and write privileges on the directory. For more information, see Grant privileges to the user on the source database.If you're copying data within subdirectories, specify the name of the subdirectory explicitly when using the rdsadmin packages. You can't copy subdirectories using the S3_INTEGRATION option.ResolutionBe sure that the DB instance has the required access to the S3 bucketTo check if your DB instance has an AWS Identity and Access Management (IAM) role with the least privileges to upload and download from S3, do the following:Open the Amazon RDS console.In the navigation pane, choose Databases.Choose the DB instance that you want to check.Choose the Connectivity & security tab.Scroll down to the Manage IAM roles section to check if you have an active IAM role with the following privileges:S3:ListBucketS3:PutObjectS3:GetObjectYou can also use the AWS Command Line Interface (AWS CLI) command describe-db-instances to check if your DB instance has an IAM role with these least privileges:aws rds describe-db-instances \--db-instance-identifier example-db-instance \--query 'DBInstances[*].[AssociatedRoles[*]]'Note: If you receive errors when running AWS CLI commands,make sure that you’re using the most recent version of the AWS CLI.After checking if the IAM role exists, do either of the following based on your finding:If the IAM role exists, but doesn't have these least privileges, then modify the role to include these permissions.If you don't have an IAM role with required permissions, then create an IAM policy with the permissions required to transfer the files from the S3 bucket to Amazon RDS. For more information, see Prerequisites for Amazon RDS for Oracle integration with Amazon S3. Be sure to add bucket level permissions to buckets and object level permissions to objects when creating the IAM policy.If the issue with bucket permissions still persists, then modify the IAM role to grant full access to the S3 bucket:{    "Version": "2012-10-17",    "Statement": [        {            "Sid": "VisualEditor0",            "Effect": "Allow",            "Action": [                "s3:*"            ],            "Resource": [                "arn:aws:s3:::example-bucket/*",                "arn:aws:s3:::example-bucket"            ]        }    ]}Important: The IAM role is modified to grant full access only to test if the issue is caused due to IAM privileges. After the issue is resolved, adjust the custom privileges as needed.To upload files to a specific folder in S3, use the p_s3_prefix parameter in the rdsadmin.rdsadmin_s3_tasks.upload_to_s3 procedure. Be sure that you have the required permissions before you upload the files.For example, to upload files to the example-folder folder to the S3 bucket example-bucket, attach the following IAM policy:{    "Version": "2012-10-17",    "Statement": [        {            "Sid": "VisualEditor0",            "Effect": "Allow",            "Action": [                "s3:PutObject",                "s3:GetObject",                "s3:ListBucket"            ],            "Resource": [                "arn:aws:s3:::example-bucket/example-folder/*"            ]        }    ]}Be sure that the DB instance is associated with an option group that includes the S3_INTEGRATION optionTo check if you have an option group attached to your RDS DB instance, do the following:Open the Amazon RDS console.In the navigation pane, choose Databases.Choose the DB instance that you want to check.Choose the Configuration tab.Note the Option groups parameter.If this option group isn't in the valid state, and you're trying to add the S3_INTEGRATION option, the option isn't added successfully. Therefore, be sure that the option group is in the valid state.To check if this option group is in valid state, run the following AWS CLI command:aws rds describe-db-instances \--db-instance-identifier example-db-instance \--query 'DBInstances[*].[OptionGroupMemberships[*]]'If the option group isn't in the valid state, choose the Logs & events tab for your database, and then scroll down to the Recent events section. Identify the component that makes the option group invalid, and remove this component from the database.If the option group is in the valid state, then check if the S3_INTEGRATION option is included in the option group. For more information, see Listing the options and option settings for an option group. If the S3_INTEGRATION option isn't included in the option group, then add the option. For more information, see Adding the Amazon S3 integration option.Note: If the S3_INTEGRATION option is not added to your DB instance, you get the error ORA-00904: "RDSADMIN"."RDSADMIN_S3_TASKS"."UPLOAD_TO_S3": invalid identifier”. This error indicates that the required procedures to upload and download aren't created on the DB instance.Adding the S3_INTEGRATION option to Amazon RDS doesn't result in downtime. If you're planning to use the Apply Immediately option, be sure that there are no pending maintenance actions. If there are any pending actions, those actions are applied along with S3 integration. For more information, see Maintaining a DB instance.Be sure that you're uploading/downloading files only from the user-created Oracle directory object or DATA_PUMP_DIR directoryYou can't access the S3 files directly in the database instance. To access these files, you must copy the files to a directory in the RDS host to access it. For uploading/downloading files from the DB instance to an S3 bucket, do the following:To copy the export files in Amazon RDS to S3, be sure to create the dump files using the expdp command or the dbms_datapump API in the DATA_DUMP_DIR or custom directory. Then, use the rdsadmin.rdsadmin_s3_tasks.upload_to_s3 procedure to upload files to S3. For information on the parameters of this procedure and example queries for uploading files, see Uploading files from an Oracle DB instance to an Amazon S3 bucket.Use the rdsadmin. rdsadmin_s3_tasks.download_from_s3 procedure to download files from the S3 bucket to the DATA_PUMP_DIR folder or any user-created directory. For information on the parameters of this procedure and example queries for download files, see Downloading files from an Amazon S3 bucket to an Oracle DB instance.To monitor the status of file transfer, view the log that's generated when you run the procedure to either upload or download the rdsadmin packages. To view these logs, do the following:Open the Amazon RDS console.In the navigation pane, choose Databases.Choose the DB instance for which you want to view the logs.Choose the Logs & events tab.Under the Logs section, enter the task ID returned by the procedure in the search filter.Select the file that's returned.Choose Watch to view the logs.-or-Choose Download to download the logs.You can also run the following command to read the log file generated during the upload/download process:SELECT text FROM table(rdsadmin.rds_file_util.read_text_file('BDUMP','dbtask-task-id.log'));Note: Be sure to replace task-id with the task ID returned by the procedure.Related informationAmazon S3 integrationHow do I resolve problems with my Amazon RDS for Oracle DB instance that's using more storage than expected?Follow"