Question: How can I connect my file gateway's NFS file share to my Windows Server?

I created a file gateway on AWS Storage Gateway. My file gateway uses VMware ESXi as the host platform. I want to connect a Network File System (NFS) file share to my Windows Server 2016 client.

Answer: "I created a file gateway on AWS Storage Gateway. My file gateway uses VMware ESXi as the host platform. I want to connect a Network File System (NFS) file share to my Windows Server 2016 client.ResolutionImportant: These steps are specific to environments running in AWS, such as those that use Amazon Elastic Compute Cloud (Amazon EC2) instances. This also includes on-premises servers that are connected to AWS.Create the file shareOpen the Storage Gateway console.From the list of gateways, select your file gateway. Then, choose Create file share.For Amazon S3 location, choose either the Amazon Simple Storage Service (Amazon S3) bucket name, S3 access point, or S3 access point alias. Then, provide the corresponding name.For AWS Region, choose the AWS Region of the S3 bucket.For File share name, enter a name for the file share.For AWS PrivateLink for S3, choose either VPC endpoint ID or VPC endpoint DNS name. Then, provide the required information in the corresponding field.For Audit logs, Automated cache refresh from S3,  and File upload notification, choose the appropriate option based on your need. Or, you can leave the default values for those fields, and then choose Next.For Configure how files are stored in Amazon S3, you can modify Storage class for new objects, Object metadata, Access to your S3 bucket, and Encryption. Or, you can leave the default values for those fields, and then choose Next.Choose Next to configure file access settings. You can modify the Allowed clients, Mount options, Export as, and File metadata defaults. Or, you can leave the default values for those fields, and then choose Next.Review the details of your NFS file share, and then choose Create file share.Wait for the file share's Status to change to Available.Note: If the file share's Status seems stuck in Creating, then check the permissions specified in the Amazon Simple Storage Service (Amazon S3) bucket policy and the AWS Identity and Access Management (IAM) role associated with the file share. The file share's role must have access to the S3 bucket.After the file share is available, select the file share so that you can view its Details tab.Note the mount command that's listed next to On Microsoft Windows.Mount the file share on your Windows ServerOn your Window Server, open Server Manager. For more information, see Server Manager%20connections%20to%20each%20server) on the Microsoft website.From the Server Manager dashboard, under Configure this local server, choose Add roles and features.In the Add Roles and Features Wizard, choose Next until you reach the Features section.For Features, confirm that Client for NFS (Installed) is selected.On your Windows client, search for the Command Prompt application. Then, open the context (right-click) menu on the Command Prompt application and choose Run as administrator.In the Administrator: Command Prompt, enter mount to display the current mounts on the Windows Server.In the next prompt, enter the mount command that you noted in step 9 of Create the file share.Note: Be sure to replace [WindowsDriveLetter] with the drive that you want to map to the S3 bucket that's associated with the file share.Run the cd command to navigate into the drive that you specified in the mount command.Run the dir command to list the files that are in the drive. Confirm that the files in the drive are the same files that are in the S3 bucket that's associated with the file share.Follow"


Question: "How do I create, launch an instance from, or troubleshoot a custom Amazon Machine Image (AMI)?"

"I want to create an Amazon Machine Image (AMI) of my existing Amazon Elastic Compute Cloud (Amazon EC2) instance. How do I create, launch an instance from, or troubleshoot an AMI?"

Answer: "I want to create an Amazon Machine Image (AMI) of my existing Amazon Elastic Compute Cloud (Amazon EC2) instance. How do I create, launch an instance from, or troubleshoot an AMI?Short descriptionAMIs are archival copies of instances that you can use to launch other instances. You can use custom AMIs in multiple scenarios based on your specific use case.ResolutionHow do I create a custom AMI?For information on creating a custom AMI, see the following:Create a custom Windows AMICreate an AMI (Linux)How do I create an AMI that's based on my Amazon Elastic Block Store (Amazon EBS)-backed EC2 instance?How to create a custom AMI with encrypted Amazon EBS snapshots and share it with other accounts and RegionsHow can I use Sysprep to create and install custom reusable Windows AMIs?How do I launch an instance from a custom AMI?For more information, see How do I launch an EC2 instance from a custom Amazon Machine Image (AMI)?How do I share a custom AMI?For information on sharing a custom AMI, see the following:How do I create and copy an Amazon Machine Image (AMI) from one AWS Region to another?How do I share an Amazon Machine Image (AMI) privately with another AWS account?How do I transfer an Amazon EC2 instance or AMI to a different AWS Account?How to share encrypted AMIs across accounts to launch encrypted EC2 instancesHow do I use VM Import/Export to export a VM based on my Amazon Machine Image (AMI)?How do I troubleshoot AMIs?For information on troubleshooting AMIs, see the following:Why can't I connect to my Amazon EC2 Windows instance that was launched from a custom AMI?Why is my EC2 AMI or EBS snapshot creation slow?Why can’t I launch EC2 instances from my copied AMI?How can I recover an accidentally deleted AMI?Why are some instance types disabled when I'm trying to launch an EC2 instance from an AMI?What can I do when the AMI that my EC2 instance uses is no longer public or when I see the error "Cannot load details for ami-xxxxxx. You may not be permitted to view it."?Related informationAWS Windows AMIsAmazon Machine Images (AMI)LinuxFollow"


Question: How do I troubleshoot issues with my Amazon EFS volume mounts in Amazon EKS?

I want to troubleshoot errors when mounting Amazon Elastic File System (Amazon EFS) volumes in my Amazon Elastic Kubernetes Service (Amazon EKS) cluster.

Answer: "I want to troubleshoot errors when mounting Amazon Elastic File System (Amazon EFS) volumes in my Amazon Elastic Kubernetes Service (Amazon EKS) cluster.ResolutionWhen you mount your Amazon EFS volume in your Amazon EKS cluster, you might get one of the following errors in your pods:"Output: mount.nfs4: mounting fs-18xxxxxx.efs.us-east-1.amazonaws.com:/path-in-dir:/ failed, reason given by server: No such file or directory""Output: Failed to resolve "fs-xxxxxx.efs.us-west-2.amazonaws.com" - check that your file system ID is correct""mount.nfs4: access denied by server while mounting 127.0.0.1:/""mount.nfs: Connection timed out""Unable to attach or mount volumes: timed out waiting for the condition"Before you begin the troubleshooting steps, verify that you have the following prerequisites:An Amazon EFS file system created with a mount target in each of the worker node subnets.A valid EFS storage class (from the GitHub website) definition using the efs.csi.aws.com provisioner.A valid PersistentVolumeClaim (PVC) definition and PersistentVolume definition. This isn't needed if you're using dynamic provisioning (from the GitHub website).The Amazon EFS CSI driver installed in the cluster.Verify that the mount targets are configured correctlyBe sure to create the EFS mount targets in each Availability Zone where the EKS nodes are running. For example, suppose that your worker nodes are spread across us-east-1a and us-east-1b. In this case, create mount targets in both Availability Zones for the EFS file system that you want to mount. If you don't correctly create the mount targets, then the pods that are mounting the EFS file system return an error similar to the following message:"Output: Failed to resolve "fs-xxxxxx.efs.us-west-2.amazonaws.com" - check that your file system ID is correct."Verify that the security group associated with your EFS file system and worker nodes allows NFS trafficYour EFS file system's security group must have an inbound rule that allows NFS traffic from the CIDR for your cluster's VPC. Allow port 2049 for inbound traffic.The security group that's associated with your worker nodes where the pods are failing to mount the EFS volume must have an outbound rule. Specifically, this outbound rule must allow NFS traffic (port 2049) to the EFS file system.If the security group doesn't allow NFS traffic, then the pods that are mounting the file system return the following errors:"mount.nfs: Connection timed out""Unable to attach or mount volumes: timed out waiting for the condition"Verify that the subdirectory is created in your EFS file system if you're mounting the pod to a subdirectoryWhen you add sub paths in persistent volumes, the EFS CSI driver doesn't create the subdirectory path in the file system. The directories must be already present for the mount operation to succeed. If the sub path isn't present in the file system, then the pods fail with the following error:"Output: mount.nfs4: mounting fs-18xxxxxx.efs.us-east-1.amazonaws.com:/path-in-dir:/ failed, reason given by server: No such file or directory"Confirm that the cluster's VPC uses the Amazon DNS serverWhen you mount the EFS with the EFS CSI driver, the EFS mount helper requires that you use the Amazon DNS server for the VPC.Note: The EFS service’s file system DNS has an AWS architectural limitation. Only the Amazon provided DNS can resolve the EFS service's file system DNS.To verify the DNS server, log in to the worker node and run the following command:nslookup fs-4fxxxxxx.efs.region.amazonaws.com AMAZON\_PROVIDED\_DNS\_IPNote: Replace region with your AWS Region. Replace AMAZON_PROVIDED_DNS_IP with your DNS IP address. By default, this is the VPC network range (10.0.0.0) plus two.If the cluster VPC uses a custom DNS server, then configure this DNS server to forward all *.amazonaws.com requests to the Amazon DNS server. If these requests aren't forwarded, then the pods fail with an error similar to the following message:"Output: Failed to resolve "fs-4 fxxxxxx.efs.us-west-2.amazonaws.com" - check that your file system ID is correct."Verify that you have "iam" mount options in the persistent volume definition when using a restrictive file system policyIn some cases, the EFS file system policy is configured to restrict mount permissions to specific IAM roles. In this case, the EFS mount helper requires that the -o iam mount option pass during the mount operation. Include the spec.mountOptions property to allow the CSI driver to add the iam mount option (from the GitHub website).The following example is a PersistentVolume specification:apiVersion: v1kind: PersistentVolumemetadata:  name: efs-pv1spec:  mountOptions:    - iam. . . . . .If you don't add the iam mount option with a restrictive file system policy, then the pods fail with an error similar to following message:"mount.nfs4: access denied by server while mounting 127.0.0.1:/"Verify that the Amazon EFS CSI driver controller service account is annotated with the correct IAM role and the IAM role has the required permissionsTo verify that the service account that the efs-csi-controller pods use has the correct annotation, run the following command:kubectl describe sa efs-csi-controller-sa -n kube-systemVerify that the following annotation is present:eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/AmazonEKS\_EFS\_CSI\_DriverRoleVerify that you completed the following steps:You created the IAM OIDC provider for the cluster.The IAM role that's associated with efs-csi-controller-sa service account has the required permissions (from the GitHub website) to perform EFS API calls.The IAM role's trust policy trusts the service account efs-csi-controller-sa. The IAM role's trust policy must look like the following example:{"Version": "2012-10-17","Statement": \[{"Effect": "Allow","Principal": {"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"},"Action": "sts:AssumeRoleWithWebIdentity","Condition": {"StringEquals": {"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:efs-csi-controller-sa"}}}\]}Verify that the EFS CSI driver pods are runningThe EFS CSI driver is made up of controller pods that are run as a deployment and node pods that are run as a DaemonSet. To verify that these pods are running in your cluster, run the following command:kubectl get all -l app.kubernetes.io/name=aws-efs-csi-driver -n kube-systemVerify the EFS mount operation from the EC2 worker node where the pod is failing to mount the file systemLog in to the Amazon EKS worker node where the pod is scheduled. Then, use the EFS mount helper to try to manually mount the EFS file system to the worker node. To test the mount operation, run the following command:sudo mount -t -efs -o tls file-system-dns-name efs-mount-point/If the worker node can mount the file system, then review the efs-plugin logs from the CSI controller and CSI node pods.Check the EFS CSI driver pod logsCheck the CSI driver pod logs to determine the cause of the mount failures. If the volume is failing to mount, then review the efs-plugin logs. To retrieve the efs-plugin container logs, run the following commands :kubectl logs deployment/efs-csi-controller -n kube-system -c efs-pluginkubectl logs daemonset/efs-csi-node -n kube-system -c efs-pluginFollow"


Question: How do I resolve login issues with QuickSight?

I'm having trouble logging in to Amazon QuickSight. How do I resolve this issue?

Answer: "I'm having trouble logging in to Amazon QuickSight. How do I resolve this issue?Short descriptionThe following are common reasons for Amazon QuickSight login issues:The user credentials are invalid.The AWS Identity and Access Management (IAM) user is deleted.AWS IAM Identity Center (successor to AWS Single Sign-On) is incorrectly set up, or the configuration changed.A custom namespace is used.The user is authenticated through an external login.The browsing data needs clearing.ResolutionIf you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.The user credentials are invalidIf you receive the error Your authentication information is incorrect, then check that you entered the correct account name and user name. Both are case sensitive. If you don't know the user name, then ask the administrator of the QuickSight account.If you're the QuickSight account administrator, then complete the following steps to check the user name:Using the Amazon QuickSight consoleOpen the Amazon QuickSight console.Choose Manage QuickSight.Using the AWS CLIRun the following command:$ aws quicksight  list-users --aws-account-id account_id --namespace name_spaceNote: Replace account_id with the QuickSight account ID and name_space with your namespace.If your user name is correct, then you might not be an active user. Ask the QuickSight administrator to resend the invitation to set up a new password to log in to the Amazon QuickSight console. If your user name is correct and you are an active user, then you might need to change your password. Only QuickSight administrators can reset passwords for active users. Ask the QuickSight administrator to reset the password for you.IAM Identity Center is incorrectly set up or configuredIf your QuickSight account uses IAM Identity Center, then it might be incorrectly set up. For more information on IAM Identity Center setup, see Using identity federation and single sign-on (SSO) with Amazon QuickSight. If you use AWS Directory Service for Microsoft Active Directory, then see Using Active Directory with Amazon QuickSight Enterprise edition and QuickSight SSO with ADFS (from the QuickSight Learning Center).If IAM Identity Center is correctly set up, then check whether the configurations changed for the following:IAM Identity Center user attributesIAM role that's associated with SAML setupIf the configuration changed, then delete the user, create a new user, and transfer resource ownership to the new user.Note: For IAM Identity Center users with user names that follow the IAM-Role-name/user-email pattern, the user name that's stored internally uses IAM-Role-identifier/user-email. If you delete the IAM role and recreate it with the same name, the underlying identifier changes. The user is then no longer accessible. Also, when you transfer resources from the old user to the new user, the new user can access only the resources that the old user created. Shared resources that are created by another user aren't transferred and must be shared again.The IAM user is deletedIf a QuickSight IAM user is no longer part of the AWS account or moved to an IAM role, then resetting the password doesn't work. To resolve this issue, delete the old IAM user, create a new IAM user, and transfer resource ownership to the new user.A custom namespace is usedCustom namespaces are accessible only to federated IAM Identity Center users. If you use password-based or credential-based Active Directory logins, then you must use the default namespace. For more information on namespaces, see Supporting multitenancy with isolated namespaces.The user is authenticated through an external loginYou receive the error The external login used for federation is unauthorized for the QuickSight user. For users that federate in to QuickSight using AssumeRoleWithWebIdentity, QuickSight maps a single role-based user to a single external login. The user might be authenticated through an external login that's different from the originally mapped user. To resolve this issue, see Individuals in my organization get an "External Login is Unauthorized" message when they try to access Amazon QuickSight.The browsing data needs clearingIf none of the preceding scenarios relate to yours, then clearing your browsing data might work for you. First, try to log in to QuickSight using a different browser. If you can log in with no issues, then clear the browsing data from the browser you normally use, and try to log in again.Related informationMy email sign-in stopped workingSigning in to Amazon QuickSightAmazon QuickSight isn't working in my browserFollow"


Question: How do I troubleshoot issues related to EC2 origins in CloudFront?

I'm using an Amazon Elastic Compute Cloud (Amazon EC2) instance as the custom origin for my Amazon CloudFront distribution. CloudFront returns an error. Why is this happening and how can I troubleshoot this?

Answer: "I'm using an Amazon Elastic Compute Cloud (Amazon EC2) instance as the custom origin for my Amazon CloudFront distribution. CloudFront returns an error. Why is this happening and how can I troubleshoot this?ResolutionBased on the type of error that CloudFront returns, see the related section for troubleshooting steps.CloudFront returns 502 errorsThere are four reasons that CloudFront returns a 502 error when Amazon EC2 is configured as the custom origin. See the following guides for troubleshooting steps:SSL/TLS negotiation failure between CloudFront and custom EC2 origin serverSSL/TLS certificate on the origin is expired, invalid, self-signed, or the certificate chain is in the wrong orderOrigin is not responding on specified ports in origin settingsCloudFront was not able to resolve your origin domain due to DNS issuesCloudFront returns 503 errorsIf your CloudFront behavior has caching turned off, all requests are directed to the origin EC2 instance instead of being service from the CloudFront cache. In this case, the origin EC2 instance can become overwhelmed with large number of incoming requests, and then returns a 503 error.For troubleshooting 503 errors, see Origin server does not have enough capacity to support the request rate.If CloudFront can't route the request to the next best available edge location, and doesn't satisfy a request, then it returns a 503: Capacity exceeded error. For more information, see CloudFront caused the error due to resource constraints at the edge location.CloudFront returns 504 errorsThere are two reasons that CloudFront returns a 504 error when Amazon EC2 is configured as the custom origin for the CloudFront distribution:The origin returned an HTTP 504 status code to CloudFront.The origin didn’t respond before the request expired.For troubleshooting steps, seeHTTP 504 status code (Gateway Timeout).Redirect errorsIf you see a redirect error in your browser, check the network section in your browser developer tools. If you see multiple instances of the same request to the CloudFront distribution, then redirections are causing the browser error.To resolve redirect errors:Check for any location headers in the response header. A location header indicates that when the request is made the redirection is sent to the value in the location header. To troubleshoot this problem, check any redirection rules or configurations on the location where the redirections are sent.Check for the Server response header. For example, if the Server value is set to the HTTP server that your EC2 server is hosting the contents on, then there is a redirection configured on the EC2 origin. Check the server in the response header to troubleshoot.Follow"


Question: How do I troubleshoot the "Command failed with exit code" error in AWS Glue?

My AWS Glue job fails and throws the "Command failed with exit code" error.

Answer: "My AWS Glue job fails and throws the "Command failed with exit code" error.Short description"Command failed with exit code X" is a generic error message that's returned when your AWS Glue application is shut down. This error occurs when one or more of the following conditions are true:The driver or executor in the AWS Glue job ran out of memory.The job script has code-related issues.The AWS Identity and Access Management (AWS IAM) role lacks the required permissions to access the script path.To further investigate this error, review the Amazon CloudWatch logs and metrics.ResolutionThe AWS Glue Spark job fails with the error "Command failed with exit code 1" and the CloudWatch logs show the error "java.lang.OutOfMemoryError: Java heap space"This AWS Glue error indicates that a driver or executor process in the job is running out of memory. To check if a driver or executor is causing the out-of-memory (OOM) exception, review the CloudWatch metrics for glue.driver.jvm.heap.usage and glue.executorID.heap.usage. For more information, see Monitoring AWS Glue using Amazon CloudWatch metrics.To troubleshoot an OOM exception caused by the driver, see How do I resolve the "java.lang.OutOfMemoryError: Java heap space" error in an AWS Glue Spark job? and Debugging a driver OOM exception.To troubleshoot an OOM exception caused by executors see Debugging an executor OOM exception.Executors fail with "Command failed with exit code 1"This error occurs when you cancel an AWS Glue job. This error also occurs when you forcefully shut down the executors, and the driver is terminated. Review the CloudWatch logs for AWS Glue for more details on the error.AWS Glue version 0.9/1.0 Spark job fails with the error "Command failed with exit code 1" and the CloudWatch logs show the error "Container killed by YARN for exceeding memory limits"Note: AWS Glue version 1.0 Spark jobs reached end of support. Upgrade to Glue 2.0 or higher for improved performance.This AWS Glue error indicates that the executor is causing an OOM exception. To troubleshoot this error, see Debugging an executor OOM exception.AWS Glue Python Shell job fails with the error "Command failed with exit code 1"This error indicates that the AWS Glue IAM role doesn't have permission to access the AWS Glue script from the Amazon Simple Storage Service (Amazon S3) path. Review the permissions that the AWS Glue IAM role must have to access the script location path. Then, attach these permissions to the IAM role.The AWS Glue job fails with the error "Command failed with exit code 1" and doesn't startCheck the CloudWatch job logs for errors that are related to Amazon S3. In the logs, you might receive an error similar to the following one:com.amazonaws.services.s3.model.AmazonS3Exception: Access Denied (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied' Request ID: xxxxxxxxxxxxx)This error occurs when the AWS Glue IAM role doesn't have permission to access the AWS Glue ETL script from the Amazon S3 path. Review the permissions that the AWS Glue IAM role must have to access the script location path. Then, attach these permissions to the IAM role.The AWS Glue job occasionally fails with "Command failed with exit code 10" and the CloudWatch logs show an error, even with the correct IAM and S3 bucket permissionscom.amazonaws.services.s3.model.AmazonS3Exception: Access Denied (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied' Request ID: xxxxxxxxxxxxx)This AWS Glue error occurs in AWS Glue versions 3.0 or 4.0. This error occurs when you're using the AWS Glue security configuration, but the S3 bucket policy denies the non-encrypted se:putObject.To resolve this issue, run job.init() at the beginning of the script to bring the AWS Glue security configuration into effect. If you start the Spark session before job.init(), then the Spark security configuration properties are overridden, and the error occurs.See the following example:job = Job(glueContext)job.init(args["JOB_NAME"], args)#Use one of the following depending on whether Spark configuration is being set or notspark = glueContext.spark_sessionspark = glueContext.spark_session.builder.enableHiveSupport().config("hive.exec.dynamic.partition","true").config("hive.exec.dynamic.partition.mode", "nonstrict").getOrCreate()For more information on AWS Glue security configuration, see Encrypting data written by crawlers, jobs, and development endpoints.The AWS Glue job fails with the error "Command failed with exit code X"and JAR files are passed to the jobYou might observe one of the following errors in the CloudWatch logs:"Exception in thread "main" java.lang.NoSuchMethodError""Exception in thread "main” java.lang.ExceptionInInitializerError"These errors indicate a JAR dependency conflict or Spark version conflict. Check the JAR executable and the extra JAR files that are passed in the job for conflict. If you're passing multiple JAR files, then remove one JAR file at a time and re-run the AWS Glue job. This way, you can isolate the file that's causing the issue.Related informationMonitoring jobs using the Apache Spark web UIWhy does my AWS Glue ETL job fail with the error "Container killed by YARN for exceeding memory limits"?Follow"


Question: How do I troubleshoot on-premises to VPC connectivity through Transit Gateway?

"I have an AWS Direct Connect or AWS Site-to-Site VPN Connection ending on AWS Transit Gateway with Amazon Virtual Private Cloud (Amazon VPC) attached to same transit gateway. However, I'm experiencing connectivity issues between my on-premises connections and the Amazon VPC. How can I troubleshoot this?"

Answer: "I have an AWS Direct Connect or AWS Site-to-Site VPN Connection ending on AWS Transit Gateway with Amazon Virtual Private Cloud (Amazon VPC) attached to same transit gateway. However, I'm experiencing connectivity issues between my on-premises connections and the Amazon VPC. How can I troubleshoot this?Short descriptionTo troubleshoot connectivity between AWS Direct Connect or AWS Site-to-Site VPN Connection ending on AWS Transit Gateway with Amazon Virtual Private Cloud (Amazon VPC) attached to same transit gateway, you can:Check the routing configuration for the transit gateway, VPC, and the Amazon EC2 instance.Use Route Analyzer in AWS Network ManagerResolutionConfirm your routing configurationsVerify the Amazon VPC subnet route table configurationOpen the Amazon VPC console.From the navigation pane, choose Route Tables.Select the route table that is used by your source Amazon Elastic Compute Cloud (Amazon EC2) instance.Choose the Routes tab.Verify that there is a route with Destination set to on-premises network.Verify that there is a Target with the value of Transit Gateway ID.Check the Availability Zones for the Transit Gateway VPC attachmentOpen the Amazon VPC console.Choose Transit Gateway Attachments.Select VPC attachment.Under Details, verify the Subnet IDs. Confirm that a subnet from your EC2 instance's Availability Zone is selected.If a subnet from the source EC2 instance isn't selected, choose Actions. Then, modify your VPC attachment, and select a subnet from your EC2 instance's Availability Zone.Note: Adding or modifying a VPC attachment subnet can impact data traffic while the attachment is in a Modifying state.Check the Transit Gateway route table associated with the VPC attachmentOpen the Amazon VPC console.Choose Transit Gateway Route Tables.Select the route table associated with the VPC attachment.In Routes tab, confirm that there is a route for on-premises network with a Target value of DXGW/VPN attachment.If you’re using a Site-to-Site VPN with Static routing: add a static route for on-premises network with target of VPN attachment.Check the Transit Gateway route table associated with the AWS Direct Connect gateway attachment or VPN attachmentOpen the Amazon VPC console.Choose Transit Gateway Route Tables.Select the route table that's associated with the AWS Direct Connect gateway attachment-or-Select the route table that's associated with the VPN attachment.In the Routes tab, confirm that there's a route for Source VPC IP range with a Target of TGW VPC attachment that corresponds to the source VPC.Check the Allowed Prefixes configured on the Direct Connect gateway to Transit Gateway associationOpen the AWS Direct Connect console.From the navigation pane, choose Direct Connect Gateways.Select the AWS Direct Connect Gateway associated with Transit Gateway.Under Gateway Association, verify that the Allowed Prefixes has a Source VPC IP Range.Confirm that the Amazon EC2 instance's security group and network access control list (ACL) allows the appropriate trafficOpen the Amazon EC2 console.From the navigation pane, choose Instances.Select the instance where you're performing the connectivity test.Choose the Security tab.Verify that the Inbound rules and Outbound rules allow traffic to and from your on-premises network.Open the Amazon VPC console.From the navigation pane, choose Network ACLs.Select the network ACL associated with the subnet where you have the instance (Source/Destination).Select the Inbound rules and Outbound rules. Verify that traffic is allowed to and from your on-premises network.Confirm that the network ACL associated with the transit gateway network interface allows the appropriate trafficOpen the Amazon EC2 console.From the navigation pane, choose Network Interfaces.In the search bar, enter Transit Gateway. All network interfaces of the transit gateway display. Note the subnet ID that's associated with the location where the transit gateway interfaces were created.Open the Amazon VPC console.From the navigation pane, choose Network ACLs.In the search bar, enter the subnet ID that you noted in step 3. The results show the network ACL that's associated with the subnet.Check the Inbound rules and Outbound rules of the network ACL to verify that it allows the Source VPC IP range and on-premises network.Confirm that on-premises firewall devices allow traffic from Amazon VPCVerify that your on-premises Firewall devices have an ingress and egress allow rule for the Source VPC IP range. Refer to your vendor's documentation for specific instructions.Use Route AnalyzerPrerequisite: Complete the steps in Getting started with AWS Network Manager for Transit Gateway networks before continuing.After you create a global network and registered your transit gateway:Access the Amazon VPC console.From the navigation pane, choose Network Manager.Choose the global network where your transit gateway is registered.From the navigation pane, choose Transit Gateway Network. Then, choose Route Analyzer.Fill in the Source and Destination information as needed. Make sure that both Source and Destination have the same Transit Gateway.Choose Run route analysis.Route Analyzer performs routing analysis and indicates a status of Connected or Not Connected. If the status is Not Connected, then Route Analyzer gives you a routing recommendation. Use the recommendations to fix the routing issues and then re-run the test to confirm the connectivity. If the connectivity issue continues, see the Confirm your routing configurations section for more troubleshooting steps.Related informationHow do I troubleshoot VPC-to-VPC connectivity through a transit gateway?Diagnosing traffic disruption using AWS Transit Gateway Network Manager Route AnalyzerFollow"


Question: What's the difference between an instance store and an EBS volume?

I want to store data that's associated with my Amazon Elastic Compute Cloud (Amazon EC2) instance. I don't know whether I should use the instance store or an attached Amazon Elastic Block Store (Amazon EBS) volume.

Answer: "I want to store data that's associated with my Amazon Elastic Compute Cloud (Amazon EC2) instance. I don't know whether I should use the instance store or an attached Amazon Elastic Block Store (Amazon EBS) volume.ResolutionSome Amazon EC2 instance types come with a form of directly attached, block-device storage known as an instance store. Use the instance store for temporary storage. Data that's stored in instance store volumes isn't persistent through instance stops, terminations, or hardware failures.For data that you want to retain longer, or if you want to encrypt the data, use Amazon EBS volumes instead. EBS volumes have the following features:EBS volumes preserve their data through instance stops and terminations.You can back up EBS volumes with EBS snapshots.You can remove EBS volumes from one instance, and reattach them to another.EBS volumes support full-volume encryption.To prevent unintentional changes or data loss, it's a best practice to frequently create snapshots. You can use AWS Backup to automate snapshot creation.Note: In Amazon EBS, the DeleteOnTermination attribute for an instance's root volume is set to true by default. If you don't change this attribute, then the instance's root volume is deleted when the instance terminates. To change the DeleteOnTermination attribute to false, see How can I prevent my Amazon EBS volumes from being deleted when I terminate Amazon EC2 instances?Related informationStorageAmazon Elastic Block Store (EBS)Amazon EBS pricingFollow"


Question: How can I troubleshoot the "internal server" error with status code 500 for API Gateway endpoints that integrate with Lambda?

"I sent an HTTP request to my Amazon API Gateway API endpoint that integrates with AWS Lambda (for example, /lambda-resource GET). I received a status code 500 response with the following error: {"message": "Internal server error"}How can I troubleshoot this error?"

Answer: "I sent an HTTP request to my Amazon API Gateway API endpoint that integrates with AWS Lambda (for example, /lambda-resource GET). I received a status code 500 response with the following error: {"message": "Internal server error"}How can I troubleshoot this error?Short descriptionThis error might be due to:Lambda function permissionsThrottling issuesIncorrect or missing HTTP status code mappingUnhandled errorsResolutionBefore you begin, follow the steps to turn on Amazon CloudWatch Logs for troubleshooting API Gateway errors.Note: For Log level, choose INFO to generate execution logs for all requests.Lambda function permissionsThe error “Invalid permissions on Lambda function” occurs if API Gateway doesn't have permissions to invoke the Lambda function. To resolve this, see How do I resolve "Invalid permissions on Lambda function" errors from API Gateway REST APIs?Note: If you used another service, such as AWS CloudFormation, to deploy your API Gateway resources, make sure that you have permissions to the AWS::Lambda::Permission resource.Throttling issuesIf the backend service is throttled due to a high number of requests, the API Gateway API might return an "Internal server error". You can activate an exponential backoff and retry mechanism and try the request again. If the issue persists, check your API Gateway quota limit. If you exceeded the service quota limit, you can request a quota increase.You might also receive "Rate exceeded" and 429 "TooManyRequestsException" errors due to Lambda function throttling issues. For more information, see How do I troubleshoot Lambda function throttling with "Rate exceeded" and 429 "TooManyRequestsException" errors?You can also request an increase for the Lambda function's concurrency limit so that the function doesn't get throttled. For instructions, see How do I request a concurrency limit increase for my Lambda function?Incorrect or missing HTTP status code mappingIncorrect or missing HTTP status code mapping can also result in 500 errors similar to the following:"Execution failed due to configuration error: Output mapping refers to an invalid method response: 2xx/4xx/5xx".To resolve this error, make sure that an API method response exists for the status code returned from the backend and is mapped correctly.Unhandled errorsUnhandled errors in Lambda indicate that the function timeouts due to errors in the function code. To prevent this error, make sure that the Lambda function code is idempotent.You can also use the debugging tool AWS X-Ray to get more details on how long different sections of your function’s code takes to complete.For more information, see Error handling patterns in Amazon API Gateway and AWS Lambda.Related informationHow can I troubleshoot 5xx errors for API Gateway?Follow"


Question: How do I stop a running query on my Amazon RDS instance that is running MySQL?

"I started a query, but I want to stop (end) the query before it finishes."

Answer: "I started a query, but I want to stop (end) the query before it finishes.ResolutionTo stop (end) a running query on an Amazon Relational Database Service (Amazon RDS) DB instance that is running MySQL, see Ending a session or query.Both queries require that you use a thread ID when calling the command. For steps to check running queries and their thread IDs, see How do I check running queries for my Amazon RDS MySQL DB instance?Related informationCommon DBA tasks for MySQL DB instancesCreating and connecting to a MySQL DB instanceFollow"


Question: How do I turn off the .opendistro-alerting-alert-history index alerts in my Amazon OpenSearch Service cluster?

There are .opendistro-alerting-alert-history indices being created in my Amazon OpenSearch Service cluster. Why is this happening and how do I turn off the .opendistro-alerting-alert-history index alerts?

Answer: "There are .opendistro-alerting-alert-history indices being created in my Amazon OpenSearch Service cluster. Why is this happening and how do I turn off the .opendistro-alerting-alert-history index alerts?ResolutionOpenSearch Service Alerting featureWhen you turn on the alerting feature in OpenSearch Service, the .opendistro-alerting-alert-history indices are created along with an alias. The alerting feature notifies users when the search criteria is met for the documents in the indices.The monitoring configurations are stored in the .opendistro-alerting-config index, while daily alerts are stored in the .opendistro-alerting-alerts index. The .opendistro-alerting-alerts index then is rolled over daily to an Alerting history index. The .opendistro-alerting-alert-history-  indices begin to populate as soon as the monitor is created and the search criteria is met.Note: To delete or modify the content of any indices, use the alerting APIs. For more information about the alerting feature, see Alerting API and Alerting indices on the Open Distro website.Turn off the daily creation of indicesTo turn off the creation of the .opendistro-alerting-alert-history-  indices, perform the following steps:1.    Go to the OpenSearch Dashboards Alerting tab.2.    Delete any monitors.3.    Delete all the alerts for the .opendistro-alerting-alert-history indices:DELETE /.opendistro-alerting-alert-history-*4.    Turn off the creation of the Alerting history:PUT _cluster/settings{     "persistent": {          "opendistro.alerting.alert_history_enabled":"false"     }}Removing old .opendistro-alerting-alert-history indices while monitoring dataYou can remove older Alerting history indices while using the monitoring feature. Your monitor configuration will not be impacted.Note: If you delete the history index for a specific day, only the Alerting history for that day is removed.Related informationConfiguring alerts in Amazon OpenSearch ServiceFollow"


Question: How do I troubleshoot the "Invalid S3 location" error when I try to save the Athena query results on an S3 bucket?

My Amazon Athena query fails to save results on the specified Amazon Simple Storage Service (Amazon S3) bucket.

Answer: "My Amazon Athena query fails to save results on the specified Amazon Simple Storage Service (Amazon S3) bucket.Short descriptionAmazon Athena automatically stores query results and metadata information for each query to a query result location that you can specify in Amazon S3. However, you get the error “Invalid S3 location” or "Not a valid S3 location" under one or more of the following conditions:You didn't specify the Amazon S3 query result location.The S3 query result location that you specified is inaccurate.The S3 query result location that you specified is in a different Region.The AWS Identity and Access Management (IAM) user doesn't have the required permissions to set up or view the query result location.ResolutionTo resolve these errors, choose one or more of the following solutions:Specify the query result locationThe query result location in Amazon S3 must be specified before you run your queries. Or, you must use a workgroup that has specified a bucket and whose configuration overrides client settings. Verify that you specified the query result location in S3 by doing the following:Open the Athena console.Choose Settings from the navigation bar.Verify that Query result location is pointing to the query result bucket.If the query result location isn't specified, then you can update it using the Athena console. You can also specify the result location in a workgroup configuration. For more information, see Specifying a query result location using a workgroup.Verify that the S3 path is accurateVerify that the query result location specified in the Athena console is pointing to the correct S3 path. Also, be sure to include a trailing slash (/) at the end of the S3 path (example: s3://doc_example_bucket/doc_example_folder/).Verify that the S3 location is in the same RegionVerify that the S3 location provided for saving the query results is in the same Region where you run the queries.Verify that the IAM user has sufficient permissions to access the query result filesVerify that the IAM user has the required permissions to access and view the query output files. The IAM user/role needs permissions to the following actions:GetObjectGetQueryResultsNote: IAM principals with permission to the GetObject action for the query results location can retrieve query results from S3. This is true even if permission to the GetQueryResults action is denied for the IAM principals. To restrict user or role access, be sure that the S3 permissions to the Athena query results location are denied.Related informationWorking with query results, output files, and query historyHow do I troubleshoot 403 Access Denied errors from Amazon S3?Why do I get the "Access Denied" error when I run a query in Amazon Athena?Follow"


Question: Can I use different Amazon Kinesis Client Library applications with the same Amazon DynamoDB table?

I'm trying to use different Amazon Kinesis Client Library (KCL) applications with the same Amazon DynamoDB table. How can I do this? What if I want to use something other than DynamoDB as a checkpointing table?

Answer:
"I'm trying to use different Amazon Kinesis Client Library (KCL) applications with the same Amazon DynamoDB table. How can I do this? What if I want to use something other than DynamoDB as a checkpointing table?Short descriptionThere are two requirements for using the KCL:Each KCL application must use its own DynamoDB table.A DynamoDB table must be used for KCL checkpointing.ResolutionCan I use different KCL applications using the same DynamoDB table?Users can't use different KCL applications with the same DynamoDB table for the following reasons:Scan operations are used to obtain leases from a DynamoDB table. Therefore, if a table contains leases of different KCL applications, each application could receive a lease that isn't related to the application itself. For more information about DynamoDB lease exceptions, see DynamoDBLeaseRefresher.java on the Amazon Web Services - Labs GitHub website.Shard IDs in streams are used as primary keys in DynamoDB tables during checkpointing. When different KCL applications use the same DynamoDB table and the same shard IDs are used in the streams, inconsistencies in checkpoints can occur.Instead, you can use an application name as the default name for a DynamoDB table, and then manually set up a table name on the KCL. Here's an example of how to set up a table name on KCL version 1.x:KinesisClientLibConfiguration kinesisClientLibConfiguration = // KCL 1.x
        new KinesisClientLibConfiguration(...)
        .withTableName(<table_name>);Note: For more information about this KinesisClientLibConfiguration code example, see KinesisClientLibConfiguration.java on the Amazon Web Services - Labs GitHub website.You can also manually set up a table name on KCL version 2.x:ConfigsBuilder configsBuilder = new ConfigsBuilder(...).tableName(<table_name>); // KCL 2.xNote: For more information about this ConfigsBuilder code example, see ConfigsBuilder.java on the Amazon Web Services - Labs GitHub website.Can I use something other than DynamoDB as a checkpointing table?Users can only use DynamoDB as a checkpointing table for the KCL. DynamoDB is required as a checkpointing table for the KCL, because the KCL behavior and implementation are interconnected with DynamoDB in the following ways:The KCL includes ShardSyncTask.java, which guarantees that shard leases in a stream are included in the DynamoDB table. This check is conducted periodically in the KCL.The KCL includes DynamoDBLeaseTaker.java and DynamoDBLeaseRenewer.java, which are components that manage and update leases in the KCL. DynamoDBLeaseTaker.java and DynamoDBLeaseRenewer.java work with DynamoDBLeaseRefresher.java to make frequent API requests to DynamoDB.When the KCL makes checkpoints, requests from DynamoDBCheckpointer.java and DynamoDBLeaseCoordinator.java are made to DynamoDB. These requests are made through DynamoDBLeaseCoordinator.java, DynamoDBLeaseRenewer.java, or DynamoDBLeaseRefresher.java.Related informationConfiguring Shards and Monitoring Change Data Capture with Kinesis Data Streams in DynamoDBFollow"


Question: How do I resolve the "Log group does not exist" error for Lambda function logs in the CloudWatch console?

"When I try to view logs for my AWS Lambda function in the Amazon CloudWatch console, I get a "Log group does not exist" error. How do I resolve the error?"

Answer: "When I try to view logs for my AWS Lambda function in the Amazon CloudWatch console, I get a "Log group does not exist" error. How do I resolve the error?Short descriptionIf there's no log group for your Lambda function when you try to view your function's logs, then CloudWatch returns the following error:"Log group does not exist. The specific log group: <log group name> does not exist in this account or region."Logs are generated after you run your function for the first time. If there's no log group after invoking the function, it's usually because there's an issue with the function's AWS Identity and Access Management (IAM) permissions.To troubleshoot a Log group does not exist error from CloudWatch, confirm the following:Your Lambda function's execution role has sufficient permissions to write logs to CloudWatch.The log group resource in the IAM policy includes the name of your function.Note: For information on permissions-related logging issues with Lambda@Edge, see Service-linked roles for Lambda@Edge.ResolutionIn the IAM console, review and edit the IAM policy for the Lambda function's execution role so that the following is true:The write actions CreateLogGroup and CreateLogStream are allowed.Note: If you don't need custom permissions for your function, then you can attach the managed policy AWSLambdaBasicExecutionRole. This managed policy allows Lambda to write logs to CloudWatch.The AWS Region specified in the Amazon Resource Name (ARN) is the same as your Lambda function's Region.The log-group resource includes the name of your Lambda function. For example, if your function is named myLambdaFunction, the associated log-group is /aws/lambda/myLambdaFunction.Below is an example policy that includes the required permissions for a Lambda role to access CloudWatch logs:{    "Version": "2012-10-17",    "Statement": [        {            "Effect": "Allow",            "Action": "logs:CreateLogGroup",            "Resource": "arn:aws:logs:region:accountId:*"        },        {            "Effect": "Allow",            "Action": [                "logs:CreateLogStream",                "logs:PutLogEvents"            ],            "Resource": [                "arn:aws:logs:region:accountId:log-group:/aws/lambda/functionName:*"            ]        }    ]}Related informationAWS Lambda permissionsFollow"


Question: Why did the running task count change in my Amazon ECS service?

The running task count in my Amazon Elastic Container Service (Amazon ECS) service has increased or decreased.

Answer: "The running task count in my Amazon Elastic Container Service (Amazon ECS) service has increased or decreased.Short descriptionThe running task count for your Amazon ECS service might increase or decrease due to multiple reasons. Some of the common causes are the following:Your Amazon ECS tasks are failing health checks.AWS CloudFormation or AWS Cloud Development Kit (AWS CDK) updated the desired count in the ECS service.You manually updated the desired count for your ECS service.The Amazon ECS Service Auto Scaling updated the number of tasks based on the scaling policy.You updated the minimum or maximum count in Application Auto Scaling using the RegisterScalableTarget API.The deployment configuration of your ECS service modified the running task count during deployment.ResolutionYour ECS tasks are failing health checksIf your tasks are using the Amazon EC2 launch type, see How can I get my Amazon ECS tasks running using the Amazon EC2 launch type to pass the Application Load Balancer health check in Amazon ECS?If the tasks are using the AWS Fargate launch type, see How do I troubleshoot health check failures for Amazon ECS tasks on Fargate?CloudFormation or AWS CDK updated the desired count in your ECS serviceIf you created your ECS service with CloudFormation or CDK without specifying the DesiredCount field, then the desired count is set to the default value of 1. However, when the service is updated through CloudFormation or CDK without specifying the DesiredCount field, the existing desired count in the current deployment is used for the new deployment.To troubleshoot this issue, review AWS CloudTrail events to check if the UpdateService API call was made by CloudFormation. You can verify this same by checking that the userAgent field in the Event record section specifies the following:"userAgent": "cloudformation.amazonaws.com"To resolve this issue, remove the desiredCount parameter from the CloudFormation or CDK code during the update.You manually updated the desired count for your ECS serviceIf you manually updated the ECS Service using the UpdateService API, Amazon ECS console, or AWS Command Line Interface (AWS CLI), then update the service again to change the desired count to an appropriate value. For more information, see Updating a service and update-service.To troubleshoot this issue, review CloudTrail events to check whether the UpdateService API call was made from the Amazon ECS console or AWS CLI. You can view this information in the userAgent field in the CloudTrail record.Example:"userAgent": "console.amazonaws.com"The Amazon ECS Service Auto Scaling updated the number of tasks based on the scaling policyThe Amazon ECS Service Auto Scaling might have increased or decreased the desired count based on the scaling policy. Review the service and check for any recent scaling activity.To view the scaling activities, do the following:Open the Amazon ECS console.In the navigation pane, choose Clusters.Choose the cluster that you want to check.Choose the Services tab.Choose the service that you want to check.Choose the Events tab.If there was a scaling event, then you might view informational messages, such as the following, in the Message column:Successfully set desired count to 1. Change successfully fulfilled by ecs. Cause: monitor alarm TargetTracking-service/service-autoscaling/sample-webapp-AlarmLow-fcd80aef-5161-4890-aeb4-35dde11ff42c in state ALARM triggered policy TargetTrackingPolicy.If the tasks are stopped due to a scaling activity, review the target tracking or step scaling policies. Then, update the desired count according to your application’s requirements.To view the Application Auto Scaling configuration, do the following:Open the Amazon ECS console.In the navigation pane, choose Clusters.Choose the cluster that you want to check.Choose the Services tab.Choose the service that you want to check.Choose the Auto Scaling tab.Note: If you're using the new Amazon ECS console, choose Configuration and tasks, and then view the information under Service configuration.You updated the minimum and maximum count in Application Auto Scaling using the RegisterScalableTarget APIIf you used the RegisterScalableTarget API to update the scalable target, then check the MinCapacity property value specified in the API. If you specified a new minimum value, then Application Auto Scaling uses this value as the new minimum value that the tasks can be scaled down to.Note: Application Auto Scaling doesn't scale down the desired count to less than the specified minimum value.The deployment configuration of your ECS service modified the running task count during deploymentReview CloudTrail events to check if the UpdateService API was called recently. You can view the deployment configuration of your ECS service by checking the deploymentConfigration request parameter in the UpdateService API.-or-Review the deployment configuration of your ECS service in the Amazon ECS console by doing the following:Open the Amazon ECS console.In the navigation pane, choose Clusters.Choose the cluster that you want to check.Choose the Services tab.Choose the service that you want to check.Choose the Deployments tab.The deployment configuration parameters control how many tasks are run during a deployment and the sequence of stopping and starting tasks. If the deployment configuration is set incorrectly, then the number of tasks running during the deployment is reduced. Therefore, it's a best practice to configure the value of the minimumHealthyPercent parameter to higher than 0%.The minimumHealthyPercent parameter represents the lower limit on either of the following as a percentage of the desired number of tasks for the service:Number of tasks that should be running for a service during a deploymentNumber of tasks that should be running when a container instance is draining.The value of this parameter is rounded up. For example, if minimumHealthyPercent is 50% and the desired number of tasks is four, then the scheduler can stop two existing tasks before starting two new tasks. If minimumHealthyPercent is 75% and the desired number of tasks is two, then the scheduler can't stop any tasks due to the resulting value also being two.The maximumPercent parameter represents the upper limit on either of the following as a percentage of the desired number of tasks for a service:Number of tasks that should be running for a service during a deploymentNumber of tasks that should be running when a container instance is draining.The value of this parameter is rounded down. For example, if maximumPercent is 200% and the desired number of tasks is four, then the scheduler can start four new tasks before stopping four existing tasks. If maximumPercent is 125% and the desired number of tasks is three, then the scheduler can't start any tasks due to the resulting value also being three.For more information, see Rolling update.Related informationService auto scalingHow do I resolve the "[AWS service] was unable to place a task because no container instance met all of its requirements" error in Amazon ECS?Follow"


Question: How do Amazon EC2 Reserved Instances that are size-flexible apply to my AWS bill?

I want to know how my Amazon Elastic Compute Cloud (Amazon EC2) Reserved Instances (RIs) apply to my AWS bill if the Reserved Instances are size-flexible.

Answer: "I want to know how my Amazon Elastic Compute Cloud (Amazon EC2) Reserved Instances (RIs) apply to my AWS bill if the Reserved Instances are size-flexible.ResolutionTo find out if your RI is size-flexible, see How can I find out if my Amazon EC2 Reserved Instance provides regional benefit or size flexibility?Size-flexible RIs apply to any usage in a particular instance family. Here are a few examples of how that can work in practice:Your RI applies to any instance in its family of its same size or smaller. For example, if you purchase an RI for an m3.large instance, the RI also applies to m3.medium instances.Multiple smaller RIs combine to apply to larger instances. For example, if you purchase two RIs for two m3.medium instances, these RIs also apply to an m3.large instance.For more examples, see How Reserved Instances are applied.RIs apply automatically to your billing. You can't choose which specific instances receive the benefit of your RIs.If you're in an organization with multiple accounts under a consolidated bill, additional considerations can apply. For more information, see How is the pricing benefit of a Reserved Instance applied across an organization's consolidated bill?Related informationAnalyzing your costs with Cost ExplorerAmazon EC2 usage reportsFollow"


Question: "Why does CloudFront show my old Amazon-issued SSL certificate, even after I renew or reimport the certificate?"

"I renewed my Amazon-issued SSL certificate on AWS Certificate Manager (ACM), or I reimported my SSL certificate to ACM. However, Amazon CloudFront still shows the previous version of the certificate."

Answer: "I renewed my Amazon-issued SSL certificate on AWS Certificate Manager (ACM), or I reimported my SSL certificate to ACM. However, Amazon CloudFront still shows the previous version of the certificate.ResolutionIf the certificate renewal or reimport process isn't yet complete, CloudFront might still use the previous certificate. Renewing or reimporting a certificate is an asynchronous process, and it can take up to 24 hours until CloudFront shows those changes.To avoid certificate expiration issues, renew or reimport your certificate at least 24 hours before the NotAfter value of your current certificate. If you're within 24 hours of the certificate expiration, then request a new certificate from ACM or import a new certificate to ACM. Then, associate the new certificate to the CloudFront distribution.Related informationManaged renewal for ACM certificatesReimporting a certificateCheck a certificate's renewal statusTroubleshooting managed certificate renewalFollow"


Question: How do I create an SNS notification that includes error information for a Data Pipeline activity?

"When an AWS Data Pipeline activity fails, I want to receive an Amazon Simple Notification Service (Amazon SNS) notification that includes specific information, such as the error stack trace."

Answer: "When an AWS Data Pipeline activity fails, I want to receive an Amazon Simple Notification Service (Amazon SNS) notification that includes specific information, such as the error stack trace.Short descriptionCreate and subscribe to an SNS topic, and then configure an SnsAlarm action to run when a Data Pipeline activity fails. You can pass any of the activity's fields, such as errorStackTrace, to SnsAlarm using the expression #{node.activityfield}. For example:{  "role": "DataPipelineDefaultRole",  "subject": "Failed PipelineId: #{node.@pipelineId} Error: #{node.errorMessage}",  "message": "Error: #{node.errorStackTrace}",  "topicArn": "arn:aws:sns:us-east-1:917786601234:DPsqlActivityFail",  "name": "DefaultActionSNS1",  "id": "SnsAlarmActionOnfail",  "type": "SnsAlarm"},ResolutionCreate and subscribe to an SNS topic. Note the Topic ARN (for example, arn:aws:sns:us-east-1:111122223333:my-topic). You'll use this later.Open the Data Pipeline console.On the List Pipelines page, choose your Pipeline ID, and then choose Edit Pipeline to open the Architect page.In the right pane, choose Activities, and then select the activity that you want to receive notifications for (for example, SqlActivity).In the Add an optional field dropdown list, choose On Fail.In the On Fail list, choose Create new: Action. Data Pipeline automatically gives the new action a name, such as DefaultAction1. You can change the name by editing the action in the Others section.In the right pane, choose Others, and then choose the action that you created in the previous step (for example, DefaultAction1).In the Type list, choose SnsAlarm.In the Message field, enter the message that you want to receive when the activity fails. You can include any of the activity's fields in the message using the expression #{node.activityfield}. For example, to receive the stack trace in the SNS notification, enter a message such as "Error: #{node.errorStackTrace}". For more information about the fields that are available for each Data Pipeline activity, see Activities.In the Subject field, enter a subject line for the notification. The subject can also include any of the activity's fields (for example, "Failed PipelineId: #{node.@pipelineId} Error: #{node.errorMessage}").In the Topic Arn field, enter the ARN of your SNS topic (for example, arn:aws:sns:us-east-1:111122223333:my-topic).Choose Save. When you activate your pipeline, you'll receive a notification if the specified activity fails.Related informationExpressionsFollow"


Question: How do I retry an unsuccessful AWS payment?

One of my AWS payments hasn’t processed successfully. How do I retry the payment?

Answer: "One of my AWS payments hasn’t processed successfully. How do I retry the payment?ResolutionIf you don't have overdue payments, then you can see your previous invoices in the Transactions tab of the Payments page.To retry most payments yourself, do the following:Open the AWS Billing console.In the navigation pane, choose Payments. You can see your overdue payments in the Payments due table.Select the invoice that you want to pay in the Payments due table, and then choose Complete payment.(Optional) On the Complete a payment page, your default payment method is selected. To use a different payment method, choose Change.Choose Verify and pay to retry the payment.If the payment doesn’t have the Complete payment option, then contact AWS Support and ask them to retry the payment for you. For example, you can't retry the Reserved Instance (RI) upfront payments through the Billing console, but AWS Support can retry them for you.Related informationManaging your accountManaging your paymentsWhy was my credit card declined when I tried to pay my AWS bill?How can I reactivate my suspended AWS account?Follow"


Question: Requesting a spending limit increase for SMS messages in Amazon SNS

"When I try to send mobile text messages (SMS), I receive a "No quota left for account" error from Amazon Simple Notification Service (Amazon SNS). I want to I request a spending limit increase for SMS messages in Amazon SNS."

Answer: "When I try to send mobile text messages (SMS), I receive a "No quota left for account" error from Amazon Simple Notification Service (Amazon SNS). I want to I request a spending limit increase for SMS messages in Amazon SNS.Short descriptionIf you reach your monthly SMS messaging spending limit, then you receive a No quota left for account error from Amazon SNS. To resolve the error, you must increase your account's spending limit for sending SMS messages in Amazon SNS.To increase your account's spending limit for sending SMS messages in Amazon SNS, you must open a quota increase case in the AWS Support Center.ResolutionOpen a quota increase case in the AWS Support CenterFor step-by-step instructions, see Requesting increases to your monthly SMS spending quota for Amazon SNS.Calculate your required SMS spending quotaImportant: Make sure that you request an SMS spending quota appropriate for your use case. AWS denies requests for high spending quotas that don't have a valid use case.Multiply the number of messages that you expect to send each month by the cost of a single message part.When calculating your required SMS spend quota, keep the following points in mind:A single SMS message can contain up to 140 bytes of information.If an SMS message contains more than the maximum number of characters, then the message splits into multiple parts.The maximum number of characters in a single SMS message depends on the type of encoding and characters you use.Example SMS messages spending quota calculation(300 messages daily x 30 days) x $0.00266 USD cost per message part x 1 total number of message parts per message = $23.94 USD spend limitNote: Each country has its own SMS pricing. For more information, see Worldwide SMS pricing.Write a description of your SMS use caseMake sure that your request for an SMS spending quota increase includes the following details:Dollar limit requestedLink or name of the site or application that's sending SMS messagesType of message that you intend to send (transactional, promotional, or one-time password)Details of your opt-in process and any other ways to make sure that you only send messages to people who have requested your messagesAWS Region from where the sender makes API calls to Amazon SNSList of countries that you plan to send messages toMaximum number of messages that you expect to send per daySMS message template that you plan to sendAny additional information that helps clarify your use caseImportant: After you receive confirmation that your SMS spending quota is increased, you must adjust the spending quota for your account on the Amazon SNS console. If you don't update your SMS settings on the Amazon SNS console, then your SMS spend limit doesn't increase.Related informationAmazon SNS endpoints and quotasSetting SMS messaging preferencesMobile text messaging (SMS)Requesting increases to your monthly SMS spending quota for Amazon SNSFollow"


Question: How do I troubleshoot the "User/IAM role X is not authorized to perform Y on resource Z" error in AWS Glue?

My AWS Glue job fails with a lack of AWS Identity and Access Management (IAM) permissions error even though I have the required permissions configured.

Answer: "My AWS Glue job fails with a lack of AWS Identity and Access Management (IAM) permissions error even though I have the required permissions configured.ResolutionIn AWS Glue, your action can fail out with lack of permissions error for the following reasons:The IAM user or role that you're using doesn't have the required permissions.The IAM user is part of an organization in AWS Organizations that has a service control policy (SCP) in place that restricts specific actionsThe subnet used has a virtual private cloud (VPC) endpoint with a policy that allows or denies some actions.The IAM user or role being used doesn't have the required permissionsSee this example of a lack of permissions error:"Failed to create job gluestudio-service.us-east-1.amazonaws.com] with exception "errorMessage":"User: arn:aws:sts::<AccountID>:assumed-role/<ConsoleAssumedRole>/<user> is not authorized to perform: iam:PassRole on resource: arn:aws:iam::<AccountID>:role/<GlueRoleName>"You can break this error down into three factors:The user/IAM role calling the action - arn:aws:iam::111111111111111:role/service-role/AWSGlue-xxxxxxThe action - iam:PassRoleThe resource that the action is being performed on - arn:aws:iam::xxxxxxxxxxxxxxxx:role/AWSGlueCheck that the user or IAM role being used has the required action on the resource.1.    Open the IAM console.2.    Search for the user or IAM role you're using, and check the policies attached to it. In the previous example, the role is arn:aws:iam::xxxxxxxxx:user/yyyyyyyyyyy.3.    Add an inline policy similar to the following that allows the required action on the resource:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "FirstStatement",      "Effect": "Allow",      "Action": ["Action"],      "Resource": "<ARN of resource>"    }  ]}Note: Replace Action and ARN of resource in this example with the specific action and resource that you previously identified from the error message.Using the previous example, your policy looks similar to this:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "PassRolePermissions",      "Effect": "Allow",      "Action": [        "iam:PassRole"      ],      "Resource": [        "arn:aws:iam::<AccountID>:role/<GlueRoleName>"      ],      "Condition": {        "StringLike": {          "iam:PassedToService": [            "glue.amazonaws.com"          ]        }      }    }  ]}An organization's SCP is preventing an action on the resourceYou might receive an error similar to the following:"createJob: AccessDeniedException: User: arn:aws:sts::111111111111111:assumed-role/xxxxxxxxxx is not authorized to perform: glue:CreateJob on resource: arn:aws:glue:region:22222222222222:job/glue-job with an explicit deny in a service control policy"This error is thrown because your IAM user is part of an organization that has SCPs in place. The SCP is preventing you from performing specific actions. To check the permissions associated with your SCP, follow these steps:1.    Open the IAM console.2.    Choose Organization Activity, and then choose the Attached SCP tab.3.    Review the SCPs attached to your IAM user. Make sure that you have the permissions to need to complete the desired action on the resource you're using.The subnet used has a VPC endpoint with a policy that allows or denies some actionsYou might receive an error similar to the following:"User: arn:aws:sts::1111111111:assumed-role/xxxxxxxxx/yyyyyyyyyyy is not authorized to perform: glue:CreateJob because no VPC endpoint policy allows the glue:CreateJob action (Service: Glue, Status Code: 400, Request ID:111111111111111)"To resolve this issue, follow these steps:1.    Open the Amazon Virtual Private Cloud (Amazon VPC) console.2.    Choose Endpoints, and then choose the VPC endpoint attached to the subnet you're using to complete your action.3.    Under Actions, choose Manage Policy.4.    Update the VPC endpoint policy with the desired action on the required resource.In this example, you update the VPC endpoint policy required to add the action glue:CreateJob:{  "Version": "2012-10-17",  "Statement": [    {      "Principal": "*",      "Effect": "Allow",      "Action": [        "glue:CreateJob"      ],      "Resource": "*"    }  ]}Related informationCreate an IAM role for AWS GlueFollow"


Question: Why isn't my credit or promotional code applying to my AWS bill?

"I added a credit or promotional code to my account, but it hasn't applied to my AWS usage. Why?"

Answer: "I added a credit or promotional code to my account, but it hasn't applied to my AWS usage. Why?ResolutionTo view the active credits on your AWS account, do the following:Open the Billing and Cost Management console.Choose Credits in the navigation pane.Common reasons that credits don't seem to be applied to the usage on your account include the following:The code isn't active on your account.The code has expired.You added the code to your account after the current billing cycle ended. The billing cycle begins on the first day of each month. Check the start date of the promotional credit. AWS applies the credits to your usage starting from the calendar month of the credit start date.The code has been used up already. Check your bill for previous months to make sure that the credit hasn't already been used up.The code doesn't apply to services that you're being billed for. Each credit applies to specific AWS services. The Applicable Products line in the Credits pane shows you what services the code applies to.The code was applied recently. Recently added credit codes might take a few hours to be visible in the Billing and Cost Management console. Credits might take up to a week to be applied to your bill on the Bills page of the Billing and Cost Management console.You were recently added to a new organization, and the credits are still applying to your former organization. Credits can only apply to one account per billing cycle. For more information, see How are credits and promotions calculated in an organization in AWS Organizations?If you recently joined an organization, any credits applied the month you join won't apply to that month's bill. Credits applied in the month that you join will apply to the next month's bill.Example: If you joined an organization on March 15 and applied a credit the same day, then the credit has the start date of March 1. Because the credit start date is prior to the date you joined the organization, the credit is applied to your April bill.Credit sharing isn't turned on for your organization. To share credits among all the accounts in your consolidated billing family, make sure that credit sharing is turned on. For more information, see Sharing AWS credits.Related informationAWS creditsRedeem your AWS Promotional CreditFollow"


Question: I want to stop using the CloudHSM Classic service

"I don't want to use AWS CloudHSM Classic anymore. Or, my trial period expired and I've decided I don't want to use CloudHSM Classic. How do I stop using CloudHSM Classic and confirm that I'm not billed for further usage?"

Answer: "I don't want to use AWS CloudHSM Classic anymore. Or, my trial period expired and I've decided I don't want to use CloudHSM Classic. How do I stop using CloudHSM Classic and confirm that I'm not billed for further usage?Short descriptionTo stop using CloudHSM Classic and stop any charges associated with the CloudHSM Classic service:Delete any logs on the HSM appliance.Zeroize your HSM appliance.De-provision your HSM appliance.ResolutionDelete the logs on your HSM applianceImportant:Deleting your AWS CloudFormation stack doesn't delete your CloudHSM Classic device. Don't delete the elastic network interface for the CloudHSM Classic device until after you confirm that the CloudHSM Classic device is no longer in your account.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.1.    From the Luna shell, rotate all logs by running the following command:lunash:> syslog rotate2.    Delete all logs by running the following command:lunash:> syslog cleanupZeroize your HSM appliance1.    Log in to the control (client) instance.2.    From the control instance, connect to your HSM appliance over SSH by using the following command, where private_key_file is your HSM's private key file and hsm_ip_address is the IP address of your HSM appliance:$ ssh -i private_key_file manager@hsm_ip_address3.    Run the following command:lunash:> hsm login4.    Intentionally enter an incorrect administrator password three times in a row. Attempting to log in as the administrator more than twice with the wrong password zeroizes your HSM appliance.De-provision your HSM applianceUse the delete-hsm command of the AWS CloudHSM CLI or the DeleteHsm AWS CloudHSM API command.To confirm that a device is successfully de-provisioned, run the DescribeHsm API call, and then verify that the device is in the TERMINATED state. A state other than TERMINATED indicates that the HSM appliance wasn't successfully zeroized before it was de-provisioned, and billing for CloudHSM Classic will continue.Note: The ListHsms API call might return a de-provisioned HSM device for up to 24 hours.For more information about de-provisioning unused CloudHSM Classic HSMs, see the CloudHSM migration guide section in the AWS CloudHSM FAQs.Related informationBacking up and restoring HSM data to a Luna SA backup HSMTroubleshooting AWS CloudHSMFollow"


Question: How do I test my connection to an Amazon ElastiCache Redis or Memcached cluster?

I want to test my connection to an Amazon ElastiCache for Redis or Amazon ElastiCache for Memcached cluster from a Linux-based client.

Answer: "I want to test my connection to an Amazon ElastiCache for Redis or Amazon ElastiCache for Memcached cluster from a Linux-based client.Short descriptionAmazon ElastiCache supports two in-memory key-value engines, Redis and Memcached. When you launch an ElastiCache cache cluster, choose your preferred engine.Note: This resolution covers testing a connection only for unplanned use. For a list of supported Redis clients, see the Redis documentation.For Memcached with Java, .NET, or PHP, it's a best practice to use ElastiCache clients with Auto Discovery. ElastiCache clients with Auto Discovery automatically identify new ElastiCache nodes when they're added to the cache cluster.ResolutionCreating the ElastiCache clusterNote: If you're connecting to an existing cluster, then proceed to the next step.For information on creating an ElastiCache Redis cluster, see Create a cluster (Amazon ElastiCache for Redis User Guide).For information on creating a Memcached cluster, see Create a cluster (Amazon ElastiCache for Memcached User Guide).Connecting to the ElastiCache Redis clusterElastiCache supports both cluster mode disabled and cluster mode enabled Redis clusters. To test a connection to these clusters, use the redis-cli or redis6-cli utility. The latest version of redis-cli and redis6-cli supports SSL/TLS to connect to clusters with encryption or authentication turned on.Download and compile the redis-cli utility on the Amazon Elastic Compute Cloud (Amazon EC2) instance that you're connecting from. For instructions on how to connect to an Amazon EC2 instance, see Tutorial: Get started with Amazon EC2 Linux instances.Note: The following example uses EC2 instances that run Amazon Linux, Amazon Linux 2, and Amazon Linux 2023. For documentation on installing and compiling redis-cli and redis6-cli with other Linux distributions, see the documentation for your specific operating system.Amazon Linux 2023sudo yum install redis6 -yAmazon Linux 2$sudo amazon-linux-extras install epel -y$sudo yum install gcc jemalloc-devel openssl-devel tcl tcl-devel -y$sudo wget http://download.redis.io/redis-stable.tar.gz$sudo tar xvzf redis-stable.tar.gz$cd redis-stable$sudo make BUILD_TLS=yesAmazon Linux$sudo yum install gcc jemalloc-devel openssl-devel tcl tcl-devel clang wget$sudo wget http://download.redis.io/redis-stable.tar.gz$sudo tar xvzf redis-stable.tar.gz$cd redis-stable$sudo CC=clang make BUILD_TLS=yesNote: By default, redis-cli uses an unencrypted TCP connection when it connects to Redis. The BUILD_TLS=yes option turns on SSL/TLS during the redis-cli compilation. If the cluster you connect to isn't encrypted, then you don't need the Build_TLS=yes option. Installing the redis6 package automatically installs redis6-cli with a default SSL/TLS support.For information on finding Redis endpoints, see Finding connection endpoints.Connecting to a cluster mode disabled unencrypted cluster1.     To connect to the cluster, run the following command. In the following example command, replace change-node-type.54awdt.ng.0001.use1.cache.amazonaws.com and 6379 with the endpoint of your cluster and your port number:Amazon Linux 2023redis6-cli -h change-node-type.54awdt.ng.0001.use1.cache.amazonaws.com -p 6379Amazon Linux and Amazon Linux 2src/redis-cli -h change-node-type.54awdt.ng.0001.use1.cache.amazonaws.com -p 6379This command returns a Redis command prompt that looks similar to the following example:change-node-type.54awdt.ng.0001.use1.cache.amazonaws.com:6379>2.    After you connect to the cluster, you can run Redis commands (on the redis.io website). The following are example Redis commands:set a "hello"OKget a"hello"quitConnecting to a cluster mode enabled unencrypted cluster1.    To connect to the cluster, run the following command. In the following example command, replace cluster-disable-rediscli.54awdt.clustercfg.use1.cache.amazonaws.com and 6379 with the endpoint of your cluster and your port number:Amazon Linux 2023redis6-cli -h cluster-disabled-rediscli.54awdt.clustercfg.use1.cache.amazonaws.com -c -p 6379Amazon Linux and Amazon Linux 2src/redis-cli -h cluster-disabled-rediscli.54awdt.clustercfg.use1.cache.amazonaws.com -c -p 6379Note: In these commands, option -c turns on cluster mode after -ASK and -MOVED redirections (on the redis.io website).The result in a Redis command prompt looks similar to the following example:cluster-disabled-rediscli.54awdt.clustercfg.use1.cache.amazonaws.com:6379>2.    You can now run Redis commands. Note that redirection occurs because you used the -c option to turn it on. If you don't turn on redirection, then the command returns the MOVED error. For more information on the MOVED error, see Redis cluster specification (on the redis.io website).Example Redis commands:set x Hi-> Redirected to slot [16287] located at 172.31.28.122:6379OKset y HelloOKget y"Hello"set z Bye-> Redirected to slot [8157] located at 172.31.9.201:6379OKget z"Bye"get x-> Redirected to slot [16287] located at 172.31.28.122:6379"Hi"Connecting to a cluster with encryption and authentication turned onTurning on AUTH is optional. However, to turn on AUTH, you must turn on in-transit encryption. For details on ElastiCache encryption and authentication, see ElastiCache in-transit encryption (TLS).To connect to both cluster mode enabled and cluster mode disabled encrypted clusters, use the --tls option with the redis-cli. If a cluster has an AUTH token set, then you can use the option -a to provide an AUTH password.Note: Starting in Redis version 7, encryption in-transit is turned on for existing ElastiCache clusters. You can change your Redis clusters' TLS configuration without re-building or re-provisioning them or impacting application availability. When turning on in-transit encryption, your overall solution remains connected to your Redis clusters.In the following examples, substitute the endpoint and port of your cluster.Connect to cluster mode disabled encrypted clustersThe following example command connects to a cluster with encryption and authentication turned on:Amazon Linux 2023redis6-cli -h master.rediscli-cluster-disabled.54awdt.use1.cache.amazonaws.com --tls -a PASSWORD -p 6379Amazon Linux and Amazon Linux 2src/redis-cli -h master.rediscli-cluster-disabled.54awdt.use1.cache.amazonaws.com --tls -a PASSWORD -p 6379The following example command connects to a cluster that has only encryption turned on:Amazon Linux 2023redis6-cli -h master.cluster-disabled-noauth.54awdt.use1.cache.amazonaws.com --tls -p 6379Amazon Linux and Amazon Linux 2src/redis-cli -h master.cluster-disabled-noauth.54awdt.use1.cache.amazonaws.com --tls -p 6379Connect to cluster mode enabled encrypted clustersThe following example command connects to a cluster with encryption and authentication turned on:Amazon Linux 2023redis6-cli -h master.rediscli-cluster-disabled.54awdt.use1.cache.amazonaws.com --tls -c -a PASSWORD -p 6379Amazon Linux and Amazon Linux 2src/redis-cli -h master.rediscli-cluster-disabled.54awdt.use1.cache.amazonaws.com --tls -c -a PASSWORD -p 6379The following example command connects to a cluster that has only encryption turned on:Amazon Linux 2023redis6-cli -h clustercfg.tlswithoutauth.54awdt.use1.cache.amazonaws.com --tls -c -p 6379Amazon Linux and Amazon Linux 2src/redis-cli -h clustercfg.tlswithoutauth.54awdt.use1.cache.amazonaws.com --tls -c -p 6379After you connect to the cluster, you can run Redis commands as shown in the preceding examples for unencrypted clusters.Redis-cli alternativeFor a short test without going through the redis-cli compilation, you can connect to a cluster that isn't cluster mode enabled. To do this, you can use telnet or openssl. In the following example commands, substitute the endpoint and port of your cluster.Note: To install the telnet utility, see the following section Connect to a Memcached cluster without in-transit encryption.After you connect, you can run Redis commands as shown in the preceding examples.The following example command connects to an encryption or authentication cluster mode disabled cluster:openssl s_client -connect master.rediscli-cluster-disabled.54awdt.use1.cache.amazonaws.com:6379If the cluster has a password set, then connect to the cluster first. After you connect, use the following command to authenticate the cluster, and then press the Enter key. In the following example command, replace Password with the password for your cluster:Auth PasswordThe following example command connects to a cluster mode disabled cluster that doesn't have encryption or authentication turned on:telnet change-node-type.54awdt.ng.0001.use1.cache.amazonaws.com 6379Connecting to an ElastiCache Memcached clusterTo connect to a Memcached cluster, use the telnet utility.Connect to a Memcached cluster without in-transit encryption1.    Install the telnet utility on the EC2 instance that you're testing a connection from.For CentOS-based systems, run the following command:$sudo yum install telnetFor Debian-based systems (Ubuntu), run the following command:$sudo apt-get install telnetFor instructions on how to connect to an Amazon EC2 instance, see Tutorial: Get started with Amazon EC2 Linux instances.2.    To connect to the endpoint, run the following example command. Replace mycachecluster.eaogs8.0001.usw2.cache.amazonaws.com with your endpoint and 11211 with the port of your node:telnet mycachecluster.eaogs8.0001.usw2.cache.amazonaws.com 11211The output looks similar to the following example:Trying 128.0.0.1...Connected to mycachecluster.eaogs8.0001.usw2.cache.amazonaws.com.Escape character is '^]'.>You're now connected to a node. You can run Memcached commands as shown in the following example output:set a 0 0 5helloSTOREDget aVALUE a 0 5helloENDConnecting to a MemCached cluster with in-transit encryptionIn-transit encryption is supported on clusters that run Memcached versions 1.6.12 and later. Telnet doesn't use encryption. To connect to an encryption-enabled MemCached cluster, use the openssl client.Note: You can turn on in-transit encryption on a cluster only when creating the cluster. You can't modify the cluster to toggle in-transit encryption on and off. For more information, see ElastiCache in-transit encryption (TLS).To connect to the endpoint, run the following example command. Replace testwithtls.qtyxq7.cfg.apse2.cache.amazonaws.com with your endpoint and 11211 with the port of your node:openssl s_client -quiet -crlf -connect testwithtls.qtyxq7.cfg.apse2.cache.amazonaws.com:11211Example output:depth=2 C = US, O = Amazon, CN = Amazon Root CA 1  verify return:1  depth=1 C = US, O = Amazon, CN = Amazon RSA 2048 M02  verify return:1  depth=0 CN = *.testwithtls.qtyxq7.apse2.cache.amazonaws.com  verify return:1You're now connected to a node. You can run Memcached commands as shown in the following example output:set a 0 0 5helloSTOREDget aVALUE a 0 5helloENDFollow"


Question: How do I troubleshoot timeout errors when writing from Flink to Kinesis Data Streams?

"I'm trying to write data from Flink to Amazon Kinesis Data Streams, but I receive a timeout or exception error. Why is this happening and how do I troubleshoot these errors?"

Answer: "I'm trying to write data from Flink to Amazon Kinesis Data Streams, but I receive a timeout or exception error. Why is this happening and how do I troubleshoot these errors?Short DescriptionFlink applications that use FlinkKinesisProducer can produce one of the following error messages:Caused by: org.apache.flink.kinesis.shaded.org.apache.http.conn.ConnectTimeoutException: Connect to kinesis.us-east-1.amazonaws.com:443 [kinesis.us-east-1.amazonaws.com/xxx.xxx.xxxx.xxx] failed: connect timed out[AWS Log: ERROR](CurlHttpClient)Curl returned error code 28These two timeout errors are caused by network problems and a lack of system resources in the environment where the Flink application is running.ResolutionUnable to connect to Kinesis Data Streams service endpointThe following error occurs when the Flink application is unable to connect to the Data Streams service endpoint:Caused by: org.apache.flink.kinesis.shaded.org.apache.http.conn.ConnectTimeoutException: Connect to kinesis.us-east-1.amazonaws.com: 443 [ kinesis.us-east-1.amazonaws.com/xxx.xxxx.xxx] failed:connect timed outIf this error repeatedly occurs, then there could be a problem with your network configuration.To resolve this issue, perform the following steps:1.    Verify that the Flink application can connect to the internet.2.    If your Flink application is running on AWS resources in a virtual private cloud (VPC), verify that the following VPC features are configured correctly:Route TableSecurity GroupsNetwork Access Control Lists (ACL)3.    (Optional) You can also use Data Stream's VPC endpoint to communicate within your VPC.Response for the submitted request wasn't returned within the configured timeout periodThe following Curl 28 error indicates that the response for the submitted request was not returned within the configured timeout period. Therefore, a timeout occurred:[AWS Log: ERROR](CurlHttpClient)Curl returned error code 28The timeout occurred because of a temporary network issue. The timeout might also be caused by too many pending requests to Data Streams, where records are sent to the Kinesis Producer Library (KPL) daemon. Records are sent to the KPL because FlinkKinesisProducer uses the KPL to send data from a Flink stream into an Amazon Kinesis stream.To resolve this issue, change the following configuration parameter of the FlinkKinesisProducer object:Request timeout period: producerConfig.put (“RequestTimeout”, “****”); IInternal Queue Size: FlinkKinesisProducer #setQueueLimit (queueLimit)It's also a best practice to update the following parameters to avoid data loss:Internal Queue Size: FlinkKinesisProducer #setQueueLimit (queueLimit)time-to-live on records: producerConfig.put("RecordTtl", "*****");For more information about calculating the value of setQueueLimit, see Backpressure on the Apache website.Follow"


Question: How do I troubleshoot low freeable memory in my RDS for SQL Server instance?

How can I troubleshoot low freeable memory in my Amazon Relational Database (Amazon RDS) for SQL Server instance?

Answer: "How can I troubleshoot low freeable memory in my Amazon Relational Database (Amazon RDS) for SQL Server instance?Short descriptionVery low freeable memory causes unexpected downtime on your instance. So, it's important to monitor memory usage on the instance and take remedial actions.Freeable memory is the amount of memory (RAM) available on the RDS instance. The total amount of memory available on an Amazon RDS instance depends on the instance class. For example, the instance class db.r5.8xlarge provides 32 vCPU and 256 GiB memory. If you provision an RDS instance with the db.r5.8xlarge instance class, the total memory on the instance class (256 GiB) is shared by the following:The operating systemAmazon RDS processesThe database engineWorker threadsBusiness Intelligence suite (SSIS, SSAS, SSRS) applications, and so on.For more information on how SQL Server uses memory, See the Memory management architecture guide on the Microsoft documentation website.ResolutionMonitor memory usage on your instanceAmazon CloudWatch metricsMonitor the Amazon CloudWatch metrics for FreeableMemory to identify low memory occurrences. Along with FreeableMemory, you can monitor the following to identify an increase in workload when available memory is low:DatabaseConnectionsCPUUtilizationReadIOPSReadThroughputWriteIOPSWriteThroughputEnhanced MonitoringEnhanced Monitoring can be turned on with different granularities, such as 1, 5, 10, 15, 30 or 60 seconds to monitor OS metrics for Microsoft SQL Server. It's a best practice to set the granularity as 1 or 5 seconds (the default is 60 seconds). You can create CloudWatch alarms to monitor your Amazon RDS for SQL Server DB instance’s memory consumption using Enhanced MonitoringTroubleshoot low freeable memoryTo troubleshoot low freeable memory issues, do the following:Limit the memory that the RDS instance usesLimit the memory that the RDS instance uses by setting max server memory to a value that doesn’t cause system-wide memory pressure. You can determine the max server memory value for your instance using the following formula:max_server_memory = total_RAM – (1 GB for the OS + memory_basis_amount_of_RAM_on_the_server)Total_RAM equals the instance class memory where the memory_basis_amount_of_RAM_on_the_server is determined as follows:If RAM on the server is between 4 GB and 16 GB: Leave 1 GB per 4 GB of RAM. For example, for a server with 16 GB, leave 4 GB.If RAM on the server is over 16 GB: Leave 1 GB per 4 GB of RAM up to 16 GB, and 1 GB per 8 GB of RAM above 16 GB.For example, if a server has 64 GB of RAM, the calculation is as follows:1 GB for the OSUp to 16 GB RAM: 16/4 = 4 GBRemaining RAM above 16 GB: (64-16)/8 = 6Total RAM to leave: 1 + 4 + 6 = 11 GBmax_server_memory: 64 – 11 = 53 GBNotes:If you're using SSIS, SSAS, or SSRS on the instance, then max_server_memory must be adjusted to accommodate these components.Example: You want to use SSRS with the RDS instance. Set the SSRS Max memory value to 10% (percentage of the total memory of the DB instance). This is about 6.4 GiB on an instance with 64 GiB memory. The max_server_memory value should be about 46 GiB (64-11-6.4).After initial configuration of max_server_memory, FreeableMemory must be constantly monitored to decide whether to increase or decrease the allocated memory.To change the max_server_memory, configure the value using a custom parameter group. The value for max_server_memory needs to be provided in MB.Note: The parameter max_server_memory is a dynamic parameter. So, a reboot isn't required for the changes to take effect.Check database connectionsEach database connection made to the instance requires some memory allocation outside the buffer pool for worker threads. So, a spike in DatabaseConnections can cause a drop in freeable memory.Verify if SSIS, SSAS, or SSRS components are used on the DB instanceUsing Amazon RDS for SQL Server option group, identify if SSIS, SSAS, or SSRS components are used on the DB instance. The memory used by these components exists outside of the max_server_memory setting. If you don't use these features, remove them by modifying the option group. Removing these features reduces the memory footprint on the instance.Monitor the DB instance using Performance InsightsUsing Performance Insights, you can monitor the DB instance for database performance analysis. You can use the Performance Insights dashboard to monitor database load, waits, queries, hosts, users, and so on. Monitoring these helps you identify potential bottlenecks that slow the instance down.Perform regular maintenance on the DB instancePerform regular index maintenance and keep statistics updated. Highly fragmented indexes can cause increase in I/O activity, which leads to more memory consumption. Similarly, outdated statistics can cause inaccurate cardinality estimation leading to selection of suboptimal query plan.Note: It's a best practice to perform index and statistics maintenance during a non-peak time or during a maintenance window.Monitor the Page Life expectancy and the Buffer Cache Hit RatioPage Life expectancy (PLE) indicates the number of seconds a page stays in the buffer pool without references.Buffer Cache Hit Ratio (BCHR) is the percent of page requests satisfied by data pages from the buffer pool.Monitoring PLE and BCHR identifies memory pressure. To monitor these metrics using Performance Insights, do the following:Open the Amazon RDS console.Select Performance Insights.Select the RDS for SQL Server instance that you want to monitor.Set the time range that you want to review the metrics for, and then select Manage Metrics.Select Database Metrics, Page Life Expectancy, Buffer Cache Hit Ratio.For optimum performance, the values for these metrics should be as high as possible. You can monitor these metrics using Performance Insights. You might see that the values for these metrics are consistently low over a period of time. If this occurs, tune the queries accessing data or increase the instance class to provide more memory.When there is memory pressure on the instance, along with low PLE and BCHR, PAGEIOLATCH wait increases. This means SQL Server is waiting for a page to be fetched from the disk and loaded into memory. Also, RESOURCE_SEMAPHORE wait might get noticed when memory requests by a query can't be honored due to memory crunch. This causes an increase in CPU usage because data pages aren't cached long enough in memory. When this occurs, SQL Server has to repeatedly access disk to access data causing performance issues.Identify the queries using the most resourcesUsing Performance Insights, capture the queries utilizing the most resources and tune them for better performance.Select the correct instance size for your workloadThe amount of memory on an instance depends on the instance type. It's important to select an instance class with adequate resources so that the DB instance has enough resources for the workload. An instance with less resources encounters performance issues, and an oversized instance wastes resources.Baseline your resource usageBaseline resource usage on the instance by monitoring metrics such as FreeableMemory, Page Life Expectancy, Buffer Cache Hit Ratio, and so on. If there is a significant increase in data volume on the instance, increase the max_server_memory value. Make sure to increase the max_server_memory value in proportion to the data volume change to maintain the same level of performance on the instance.Notes: You can use SQL Server native tools like Reports and DMVs to identify components using memory inside SQL Server. Using SQL Server Management Studio (SSMS), you can review SQL Server memory usage:Open SQL Server Management Studio (SSMS) and connect to your RDS for SQL Server instance.In Object Explorer, right-click the RDS instance endpoint name.Select Reports,Standard Reports, Memory Consumption.Also, you can query sys.dm_os_memory_clerks DMV to identify the components that use the maximum memory inside SQL Server.Follow"