Question: Why is my Amazon EMR cluster unreachable?

I can't connect to my Amazon EMR cluster.

Answer: "I can't connect to my Amazon EMR cluster.Short descriptionThe following are common reasons that your EMR cluster might be unreachable:There's a permissions issue in the security group rules.The network setup is incorrect for clusters that are provisioned in a private subnet.There's an issue with cluster authentication setup.There are resource constraints in the cluster nodes.The Amazon EMR service daemon is stopped.ResolutionAmazon EMR security group rules1.    Verify that the security group rules are correct. For more information, see Working with Amazon EMR-managed security groups.2.    Verify that TCP on port 8443 is allowed. Port 8443 allows the cluster manager to talk to the cluster master node.3.    Verify that SSH on port 22 is allowed, if you're trying to connect to the cluster through SSH.    If outside users or applications are not able to reach the EMR cluster, then validate the related rules that are set in managed-security groups. Also validate the rules in additional security groups.EMR clusters in a private subnetIn addition to the items mentioned in the previous section, verify the following for EMR clusters that are in a private subnet:1.    Verify that the additional managed security group for service access is added. Verify that the rules allow the cluster manager to communicate with the cluster nodes. For more information, see Amazon EMR-managed security group for service access (private subnets).2.    If you're using a bastion host and you can't reach Amazon EMR through the bastion host, then do the following:Verify that the bastion host security group allows inbound traffic from the client system.Verify that the EMR cluster security groups allow inbound traffic from the bastion host.As network configuration setups vary, make sure that the end-to-end connection is properly set without any black holes.Authentication methodsTo make sure that authentication is set up correctly, do the following:1.    If authentication uses an Amazon Elastic Compute Cloud (Amazon EC2) keypair, then verify that it's created and configured correctly. For more information, see Use an Amazon EC2 key pair for SSH credentials.2.    If authentication uses Kerberos, verify that it is configured correctly. For more information, see Use Kerberos authentication.Resource constraints in the cluster nodes1.    Verify that the underlying master node is in running state and isn't terminated.2.    Check the Instance-state log of the master node to determine how resources are being used.Run the following command to check for the top CPU user:ps auxwww --sort -%cpu | head -10Run the following command to check the kernel's performance:dmesg | tail -n 25Run the following command to check memory usage:free -mRun the following command to check disk usage:df -hEMR cluster daemonsThe master node's instance controller (I/C) is the daemon that runs on the cluster nodes. The instance controller communicates with the Amazon EMR control plane and the rest of the cluster. Run the following commands to make sure that it's in running state:Run the following command to check the status of the instance controller:sudo systemctl status instance-controllerRun the following command to start the instance controller:sudo systemctl start instance-controllerFollow"


Question: Why am I not able to connect to my AWS Glue development endpoint using SSH?

I'm unable to connect to my AWS Glue development endpoint using SHH.-or-I'm unable to use SSH port forwarding to connect to my AWS Glue development endpoint.

Answer: "I'm unable to connect to my AWS Glue development endpoint using SHH.-or-I'm unable to use SSH port forwarding to connect to my AWS Glue development endpoint.ResolutionConnect to development endpoint using SSHBe sure that you've changed the permissions on your key pair file in the development endpoint. Confirm that only you can view the file by running the following command:$ chmod 400 my-key-pair.pemConfirm the following:The path to your private key is correct.The private extension is .pem and enclosed in double quotes.Be sure to check the network connectivity to the development endpoint on port 22 using tools such as Telnet or Netcat.Be sure that your security group allows traffic from your IP address on port 22. Check if the rule for the outbound traffic is correct. The rule for the outbound traffic must confirm that the outbound traffic is open to all ports. Or, the rule must be a self-referencing rule with the following parameters: Type as All TCP, Protocol as TCP, Port Range as ALL, and Source with the same security group name as the Group ID. For more information, see Setting up your network for a development endpoint.Be sure that the Edit DNS Hostnames setting is turned on in the virtual private cloud (VPC) used for the AWS Glue development endpoint. Also, confirm that the Amazon Simple Storage Service (Amazon S3) endpoint is attached to the VPC subnet used for the development endpoint.If you are using PuTTY as the SSH client, then convert your private .pem file to a .ppk file using the PuTTYgen tool.Connect to development endpoint using SSH port forwardingSSH port forwarding requires a public DNS address to connect to the development endpoint. To add a public DNS address to your development endpoint, do the following:1.    Create a development endpoint with a VPC.2.    In the AWS Glue console, choose Dev endpoints. Note the Private address for your development endpoint. You will use this address in the next step.3.    In the Amazon Elastic Compute Cloud (Amazon EC2) console, choose Network & Security from the navigation pane. Then, choose Network Interfaces. In the Network interfaces page, search for the Private IPv4 DNS address that corresponds to the Private Address field on your development endpoint.4.    Allocate an Elastic IP address and associate the address to the elastic network interface using the following instructions:For Resource type, choose Network interface.For Network interface, choose the elastic network interface that you noted in the previous step.Verify that the address in the Private IP address field is same as the IP address of your endpoint.5.    To validate the setup, use the command similar to the following to check if you can connect to the development endpoint using SSH:ssh -i dev-endpoint-private-key.pem glue@elastic-ip6.    If you can connect successfully using this command, then use the same Elastic IP address in the actual command:ssh -i private-key-file-path -NTL 9007:169.254.76.1:9007 glue@elastic_ipFor more information, see Accessing your development endpoint.Note: If you are trying to connect a Jupyter notebook to a development endpoint and can't create a port forwarding tunnel, then check the port in the ssh command. Be sure that the port used in the command is 8998 instead of 9007.For more information, seeTutorial: Set up a Jupyter notebook in JupyterLab to test and debug ETL scripts.Related informationManaging your development endpointFollow"


Question: How do I copy and restore an Amazon Redshift Serverless snapshot to a different AWS account?

I want to copy and restore an Amazon Redshift Serverless snapshot from one AWS account to another AWS account. How can I do that?

Answer: "I want to copy and restore an Amazon Redshift Serverless snapshot from one AWS account to another AWS account. How can I do that?ResolutionPerform a copy and restore from one AWS account to another using the Amazon Redshift console or AWS Command Line Interface (AWS CLI).Before you begin, consider the following:You can restore a snapshot to an Amazon Redshift Serverless namespace only if it's in Available status and is associated with an available workgroup.Restoring an Amazon Redshift Serverless namespace from a snapshot replaces all of the namespace's databases with databases in the snapshot.During the Restore, Amazon Redshift Serverless will be unavailable.Copy and restore using the Amazon Redshift consoleConvert a recovery point of Amazon Redshift Serverless to a snapshot in the source accountOpen the Amazon Redshift console.In the navigation pane, choose Redshift serverless, and then choose Data backup.Under Recovery points, choose the Creation time of the recovery point that you want to convert to a snapshot.Choose Create snapshot from recovery point.Enter a Snapshot identifier and retention period.Choose Create.Share the snapshot in the source account with another AWS accountOpen the Amazon Redshift console.In the navigation pane, choose Redshift serverless, and then choose Data backup.Choose the snapshot you created previously.Choose Actions, Manage access.Choose Add AWS account located under Provide access to serverless accounts and enter an AWS account ID (destination).Choose Save changes.Restore the snapshot to an Amazon Redshift Serverless namespace in the destination accountOpen the Amazon Redshift console.In the navigation pane, choose Redshift serverless, and then choose Data backup.Choose the snapshot shared to the AWS account ID to restore. You can restore only one snapshot at a time.Choose Actions, Restore to serverless namespace.Choose an available namespace to restore to. You can restore to only namespaces with an Available status.Choose Restore.Copy and restore using the AWS CLINote: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.Convert a recovery point of Amazon Redshift Serverless to a snapshot in the source account1.    Use the list-recovery-points command for a list of snapshots created after a start-time. Run the following command, and replace namespacename with your namespace, us-west-2 with your AWS Region, and starttime with your recovery point start time in UTC:aws redshift-serverless list-recovery-points --namespace-name <namespacename> --region <region name> --start-time <starttime>In the following example, the Redshift Serverless cluster is in the US West (Oregon) Region with a namespace of default and a start time of 2022-09-06T07:10 UTC:aws redshift-serverless list-recovery-points --namespace-name default --region us-west-2 --start-time 2022-09-06T07:102.    Use the convert-recovery-point-to-snapshot command to create a snapshot and retention period. Run the following command, and replace recoveryPointId with the recovery point ID output from step 1, days with the number of days to retain the snapshot, snapshot name with your snapshot's name, and us-west-2 with your AWS Region:aws redshift-serverless convert-recovery-point-to-snapshot --recovery-point-id <recoveryPointId> --retention-period <days> --snapshot-name <snapshot name> --region <region name>In the following example, the snapshot is named snapshot01 with a retention period of three days, and is in the US West (Oregon) Region**.**aws redshift-serverless convert-recovery-point-to-snapshot --recovery-point-id 72acee50-34df-45f6-865f-46aa178ada82 --retention-period 3 --snapshot-name snapshot01 --region us-west-23.    Use the get-snapshot command to confirm the snapshot was created. Run the following command, and replace snapshot name with the name of your snapshot:aws redshift-serverless get-snapshot --snapshot-name <snapshot name>Share the snapshot in the source account with another AWS accountUse the put-resource-policy command to provide another AWS account access to the snapshot. Run the following command, and replace destination account ID with the destination AWS account ID and snapshot arn with the snapshot's ARN:aws redshift-serverless put-resource-policy --policy "{\"Version\": \"2012-10-17\", \"Statement\" : [{ \"Sid\": \"AllowUserRestoreFromSnapshot\", \"Principal\":{\"AWS\": [\”<destination account ID>\”]}, \"Action\": [\"redshift-serverless:RestoreFromSnapshot\"] , \"Effect\": \"Allow\" }]}" --resource-arn <snapshot arn>In the following example, access is provided to the snapshot ARN in account number 123456789012:aws redshift-serverless put-resource-policy --policy "{\"Version\": \"2012-10-17\", \"Statement\" : [{ \"Sid\": \"AllowUserRestoreFromSnapshot\", \"Principal\":{\"AWS\": [\"123456789012\"]}, \"Action\": [\"redshift-serverless:RestoreFromSnapshot\"] , \"Effect\": \"Allow\" }]}" --resource-arn arn:aws:redshift-serverless:us-west-2:112233445566:snapshot/4978ca91-24ba-4196-91ad-9d372f72b0feRestore the snapshot to an Amazon Redshift Serverless namespace in the destination account1.    Use the list-snapshots command to list the snapshot in your AWS Region. Run the following command, and replace us-west-2 with your AWS Region:aws redshift-serverless list-snapshots  --region us-west-22.    Use the restore-from-snapshot command to restore the snapshot to an Amazon Redshift Serverless. Run the following command, and replace snapshot name with the name of your snapshot, workgroup name with the name of your workgroup, and snapshot arn with the snapshot ARN from the preceding command:aws redshift-serverless  restore-from-snapshot --namespace-name <namespace name > --workgroup-name <workgroup name> --snapshot-arn <snapshot arn>In the following example, the account ID 112233445566 has an Amazon Redshift Serverless in Available state with a namespace name of restore and a workgroup name of restore:aws redshift-serverless restore-from-snapshot --namespace-name restore --workgroup-name restore --snapshot-arn arn:aws:redshift-serverless:us-west-2:112233445566:snapshot/4978ca91-24ba-4196-91ad-9d372f72b0feFollow"


Question: Why doesn't the CurrItems metric in my Memcached cluster decrease when the keys expire?

Answer: "Why doesn't the CurrItems metric in my Memcached cluster decrease when the keys expire?ResolutionThis is an expected behavior. Memcached uses lazy expiration to remove keys when the time to live (TTL) expires. This means that the key isn't removed from the node even though it's expired. However, when someone tries to access an expired key, Memcached checks the key, identifies that the key is expired, and then removes it from memory.If there are no free chunks or free pages left in the appropriate slab class to accommodate new keys, then Memcached removes the expired keys, or uses a least recently used (LRU) algorithm to evict keys if it can't find an already expired key. The CurrItems metric decreases after the keys are removed from memory.The lru_crawler thread, which is an optional background thread, also clears expired keys from memory. The lru_crawler is a conservative task, and, even if enabled, has limited action over expired keys. Therefore, even with lru_crawler enabled, it might take some time for the CurrItems metric and keyspace memory to show a decrease in usage.Use TTL to make a key available for a particular amount of time. When the key becomes invalid (expires), it's eventually removed. Keys can't be retrieved after their expiration time.Related informationMemcached specific parametersFollow"


Question: How do I delay Auto Scaling termination of unhealthy Amazon EC2 instances so I can troubleshoot them?

"My Amazon Elastic Compute Cloud (Amazon EC2) instance was marked as unhealthy and moved to the "Auto Scaling Terminating" state. Then, my Amazon EC2 instance terminated before I could determine the cause of the problem."

Answer: "My Amazon Elastic Compute Cloud (Amazon EC2) instance was marked as unhealthy and moved to the "Auto Scaling Terminating" state. Then, my Amazon EC2 instance terminated before I could determine the cause of the problem.Short descriptionAdd a lifecycle hook to your AWS Auto Scaling group to move instances in the Terminating state to the Terminating:Wait state. In this state, you can access instances before they're terminated, and then troubleshoot why they were marked as unhealthy.By default, an instance remains in the Terminating:Wait state for 3600 seconds (1 hour). To increase this time, use the heartbeat-timeoutparameter in the put-lifecycle-hook API call. The maximum time that you can keep an instance in the Terminating:Wait state is 48 hours or 100 times the heartbeat timeout, whichever is smaller.ResolutionNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent version of the AWS CLI.Use the following steps to configure a lifecycle hook using the AWS CLI. Then, create the necessary Amazon Simple Notification Service (Amazon SNS) topic and AWS Identity and Access Management (IAM) permissions.Or, you can configure a lifecycle hook using the AWS Management Console. Then, refer to the following to manage Amazon SNS topics and IAM permissions in the console:Creating a role to delegate permissions to an AWS serviceTutorial: Creating an Amazon SNS topicCreate an Amazon SNS topic1.    Create a topic where AWS Auto Scaling can send lifecycle notifications. The following example calls the create-topic command to create the ASNotifications topic:$ aws sns create-topic --name ASNotificationsAn Amazon Resource Name (ARN) similar to the following is returned:"TopicArn": "arn:aws:sns:us-west-2:123456789012:ASNotifications"2.    Create a subscription to the topic. You must have a subscription to receive the LifecycleActionToken that's required to extend the heartbeat timeout of the pending state or complete the lifecycle action. The following example uses the subscribe command to create a subscription that uses the email protocol (SMTP) with the endpoint email address user@amazon.com.$ aws sns subscribe --topic-arn arn:aws:sns:us-west-2:123456789012:ASNotifications --protocol email --notification-endpoint user@amazon.comConfigure IAM permissionsIAM permissions are configured by creating an IAM role that grants the AWS Auto Scaling service permissions to send to the SNS topic. To complete this task, create a text file that contains the appropriate policy. Then, reference the file in the create-role command.1.    Use a text editor (such as vi) to create the text file:$ sudo vi assume-role.txt2.    Paste the following in the text file, and then save the file.{  "Version": "2012-10-17",  "Statement": [{      "Sid": "",      "Effect": "Allow",      "Principal": {        "Service": "autoscaling.amazonaws.com"      },      "Action": "sts:AssumeRole"    }  ]}3.    Use the aws iam create-role command to create the IAM role AS-Lifecycle-Hook-Role from the policy saved to assume-role.txt:$ aws iam create-role --role-name AS-Lifecycle-Hook-Role --assume-role-policy-document file://assume-role.txtThe output contains the ARN for the role. Be sure to save both the ARN of the IAM role and the SNS topic.4.    Add permissions to the role to allow AWS Auto Scaling to send SNS notifications when a lifecycle hook event occurs. The following example uses the attach-role-policy command to attach the managed policy AutoScalingNotificationAccessRole to the IAM role AS-Lifecycle-Hook-Role:$ aws iam attach-role-policy --role-name AS-Lifecycle-Hook-Role --policy-arn arn:aws:iam::aws:policy/service-role/AutoScalingNotificationAccessRoleThis managed policy grants the following permissions:{  "Version": "2012-10-17",  "Statement": [{      "Effect": "Allow",      "Resource": "*",      "Action": [        "sqs:SendMessage",        "sqs:GetQueueUrl",        "sns:Publish"      ]    }  ]}Important: The AWS managed policy AutoScalingNotificationAccessRole allows the AWS Auto Scaling service to make calls to all SNS topics and queues. To restrict AWS Auto Scaling's access to only specific SNS topics or queues, use the following sample policy.{  "Version": "2012-10-17",  "Statement": [{      "Effect": "Allow",      "Resource": "arn:aws:sns:us-west-2:123456789012:ASNotifications",       "Action": [         "sqs:SendMessage",         "sqs:GetQueueUrl",         "sns:Publish"       ]     }   ]}Configure the lifecycle hookNext, use the put-lifecycle-hook command to configure the lifecycle hook:aws autoscaling put-lifecycle-hook --lifecycle-hook-name AStroublshoot --auto-scaling-group-name MyASGroup        --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING        --notification-target-arn arn:aws:sns:us-west-2:123456789012:ASNotifications        --role-arn arn:aws:iam::123456789012:role/AS-Lifecycle-Hook-Role Be sure to substitute your own AWS Auto Scaling group name, SNS target ARN, and IAM role ARN before running this command.This command:Names the lifecycle hook (AStroubleshoot)Identifies the AWS Auto Scaling group that is associated with the lifecycle hook (MyASGroup)Configures the hook for the instance termination lifecycle stage (EC2_INSTANCE_TERMINATING)Specifies the SNS topic's ARN (arn:aws:sns:us-west-2:123456789012:ASNotifications)Specifies the IAM role's ARN (arn:aws:iam::123456789012:role/AS-Lifecycle-Hook-Role)Test the lifecycle hookTo test the lifecycle hook, choose an instance and then useterminate-instance-in-auto-scaling group to terminate the instance. This forces AWS Auto Scaling to terminate the instance, similar to when the instance becomes unhealthy. After the instance moves to theTerminating:Wait state, you can keep your instance in this state usingrecord-lifecycle-action-heartbeat. Or, allow the termination to complete usingcomplete-lifecycle-action.aws autoscaling complete-lifecycle-action --lifecycle-hook-name my-lifecycle-hook        --auto-scaling-group-name MyASGroup --lifecycle-action-result CONTINUE        --instance-id i-0e7380909ffaab747Related informationAmazon EC2 Auto Scaling lifecycle hooksFollow"


Question: How do I host multiple public websites using IIS on the same EC2 Windows Server instance?

I want to use Internet Information Services (IIS) to host multiple websites on a single Amazon Elastic Compute Cloud (Amazon EC2) Windows Server instance.

Answer: "I want to use Internet Information Services (IIS) to host multiple websites on a single Amazon Elastic Compute Cloud (Amazon EC2) Windows Server instance.ResolutionIf you have multiple public websites, then you can host them in IIS on the same EC2 Windows Server instance. IIS uses bindings to differentiate between websites. Bindings are a combination of the protocol type, IP address, port, and hostname. To avoid IP address and port conflicts, you must add a hostname.To configure the IIS server on your instance to host multiple websites, follow these steps:Set up your websites on the EC2 Windows Server instance. Make sure to install and configure IIS (from the Microsoft website) on the instance.Use the Amazon EC2 console to get the IP addresses of the EC2 Windows Server instance.Use Remote Desktop Protocol to connect to the instance.Open IIS Manager. In the Connections pane, choose the site that you want to add a hostname to.In the Actions pane, complete the following steps:Choose Bindings.Choose Edit.In the hostname field, enter a name.Choose OK.Update the hosts file with the hostname to access the website locally from the IIS server:Open a text editor with the Run as Administrator option, and then open the hosts file in the C:\Windows\System32\drivers\etc directory.Enter the private IP address of the EC2 instance and the hostname of your website, and then save the file.Repeat steps 4 through 6 for each additional website.To access your websites, use the private IP address locally from the hosts file on the same EC2 Windows Server instance. For public access, use your DNS host provider or Amazon Route 53 to add the public IP address in your public hosted zone.Follow"


Question: How can I troubleshoot why Amazon Redshift switched to one-by-one mode because a bulk operation failed during an AWS DMS task?

I have an AWS Database Migration Service (AWS DMS) task that is migrating data to Amazon Redshift as the target. But my task changed to one-by-one mode because a bulk operation failed. How do I troubleshoot this issue?

Answer: "I have an AWS Database Migration Service (AWS DMS) task that is migrating data to Amazon Redshift as the target. But my task changed to one-by-one mode because a bulk operation failed. How do I troubleshoot this issue?Short descriptionDuring the change data capture (CDC) phase of a task, AWS DMS uses a single thread to read change data from the source and apply changes to the target. Because the thread can handle only a certain number of transactions at a time, depending on the rate of changes on the source, sometimes the thread can't keep the target in sync with the source. This happens more often when Amazon Redshift is the target for AWS DMS because commits are expensive in OLAP engines. By default, AWS DMS uses Batch Apply mode to process the changes in batches. When using Batch Apply mode, AWS DMS does the following:Collects changes from a batch that is controlled by Batch Apply settings.Creates a net changes table that contains all the changes from the batch to the target instance.Uses an algorithm that groups transactions and applies them in bulk to the target.When a migration task that is replicating data to Amazon Redshift has an issue applying a batch, AWS DMS doesn't fail the whole batch. AWS DMS breaks the batch down and switches to one-by-one mode to apply transactions. When AWS DMS encounters the transaction that caused the batch to fail, AWS DMS logs the transaction to the awsdms_apply_exceptions table on the Amazon Redshift target. Then, AWS DMS applies the other transactions in the batch one by one until all transactions from that batch are applied onto the target. Finally, AWS DMS switches back to Batch Apply mode for a new batch and continues to use Batch Apply unless another batch fails.ResolutionYou can see whether your batch failed and AWS DMS used one-by-one mode by checking the AWS DMS task log. Each time a batch fails and AWS DMS switches to one-by-one mode, you see the following log entry:Messages[TARGET_APPLY ]I: Bulk apply operation failed. Trying to execute bulk statements in 'one-by-one' mode (bulk_apply.c:2175)When this happens, AWS DMS applies transactions sequentially onto the target until AWS DMS encounters an issue with any transaction in the batch. If AWS DMS encounters an issue, it logs the transaction and you see a log entry similar to the following:Messages[TARGET_APPLY ]W: Source changes that would have had no impact were not applied to the target database. Refer to the 'awsdms_apply_exceptions' table for details. (endpointshell.c:5984)Note: By default, the awsdms_apply_exceptions table is created in the public schema, unless you specify a control table schema in the task settings of your AWS DMS task.After AWS DMS logs the transaction, it completes the application of all the transactions from that batch. Then, AWS DMS switches to Batch Apply again, and you see a message in the log that is similar to the following:Messages[TARGET_APPLY ]I: Switch back to bulk apply mode (bulk_apply.c:4751)Amazon Redshift is an OLAP data warehouse that is optimized to run complex analytic queries. However, Amazon Redshift performance can be affected when running transactional changes from an OLTP database. As a result, when Batch Apply fails and AWS DMS switches to one-by-one mode, you can see that target latency increases for the duration of the time that AWS DMS runs transactions in a one-by-one mode. After AWS DMS switches back to Bulk Apply, the target latency reduces.To resolve this issue, connect to the Amazon Redshift target. Then, get the output from the awsdms_apply_exceptions table to identify the query that caused the batch to fail:select * from public.awsdms_apply_exceptions order by 4 desc;After you find the query that caused the batch to fail (for example, update conflicts or constraint violations), then you can resolve the conflicts to prevent tasks from moving to one-by-one mode.Related informationDebugging Your AWS DMS Migrations: What to Do When Things Go WrongUsing an Amazon Redshift Database as a Target for AWS Database Migration ServiceFollow"


Question: How do I troubleshoot RBAC issues with Amazon EKS?

"When I use my Amazon Elastic Kubernetes Service (Amazon EKS) cluster, I want to troubleshoot errors, such as Access Denied, Unauthorized, and Forbidden."

Answer: "When I use my Amazon Elastic Kubernetes Service (Amazon EKS) cluster, I want to troubleshoot errors, such as Access Denied, Unauthorized, and Forbidden.Short descriptionAWS Identity and Access Management (IAM) provides authentication to the cluster, and relies on native Kubernetes role-based access control (RBAC) for authorization. When an IAM user or role creates an Amazon EKS cluster, the IAM entity is added to the Kubernetes RBAC authorization table with system:masters permissions.To add users with administrator access to an Amazon EKS cluster, complete the following steps:Allow the required IAM console permissions for the associated IAM users so that users can perform the necessary cluster operations.Update the aws-auth ConfigMap to provide the additional IAM users with the cluster role and role bindings. For more information, see Add IAM users or roles to your Amazon EKS cluster.Note: The aws-auth ConfigMap doesn't support wildcards. It's a best practice to use eksctl to edit the ConfigMap. Malformed entries can lead to lockout.Run the following kubectl auth can-i command to verify that RBAC permissions are set correctly:kubectl auth can-i list secrets --namespace dev --as daveWhen you run the kubectl command, the authentication mechanism completes the following main steps:Kubectl reads context configuration from ~/.kube/config.The AWS Command Line Interface (AWS CLI) command aws eks get-token is run to get credentials, as defined in .kube/config.The k8s api request is sent and signed with the preceding token.Note: You can't modify the 15-minute expiration on the token that's obtained through aws eks get-token.ResolutionNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.Authentication issuesError: "The cluster is inaccessible due to the cluster creator IAM user being deleted"If you receive the preceding error, then you must re-create the cluster creator IAM user with the same name as the cluster. To do this, find information on the cluster admin and cluster creator.If you created the cluster within the last 90 days, then you can search AWS CloudTrail for CreateCluster API calls. Cluster creator permissions are identical to system:masters permissions. If you have other users with system:masters permissions, then you aren't dependent on the cluster creator. If you previously authenticated with the Amazon EKS cluster, then you can review previous authenticator logs in the Amazon CloudWatch log group. Use the following CloudWatch Logs Insights query to check the cluster admin user and role details:fields @timestamp, @message| sort @timestamp desc| filter @logStream like /authenticator/| filter @message like "system:masters"To re-create the cluster creator IAM user and role, run the following commands:Important: Make sure to check all AWS CLI commands and replace all instances of example strings with your required values. For example, replace EXAMPLE-USER with your username.aws iam create-user --user-name <EXAMPLE-USER>aws iam create-role --role-name <EXAMPLE-ROLE>Error: "Could not be assumed because it does not exist or the trusted entity is not correct or an error occurred when calling the AssumeRole operation"If you receive the preceding error, then verify that the trust policy correctly grants assume permissions to the user. For more information, see IAM tutorial: Delegate access across AWS accounts using IAM roles.To identify local users that deploy the Amazon EKS cluster by default, run the following command:kubectl get clusterroles -l kubernetes.io/bootstrapping=rbac-defaultsTurn off anonymous access for API actions. Anonymous users have subject set to name: system:unauthenticated. To identify anonymous users, run the following command:kubectl get clusterrolebindings.rbac.authorization.k8s.io -o json | jq '.items[] | select(.subjects[]?.name=="system:unauthenticated")'For more information, see the Amazon EKS best practices guides.Authorization issuesError: "Couldn't get current server API group list"To troubleshoot the preceding error, see Unauthorized or access denied (kubectl).Error: "You must be logged in to the server (Unauthorized)"To troubleshoot the preceding error, see How do I resolve the error "You must be logged in to the server (Unauthorized)"?Error: "You must be logged in to the server (the server has asked for the client to provide credentials)"The preceding error occurs when you use an IAM entity to make API calls and didn't correctly map the IAM entity. You must map the IAM entity to an Amazon EKS role in the cluster's aws-auth ConfigMap. For more information, see Turning on IAM user and role access to your cluster.Error: "Can't describe cluster control plane: AccessDeniedException"The preceding error occurs when you update the kubeconfig with a user and a role who don't have permission to perform the eks:DescribeCluster action.Error: "Current user or role does not have access to Kubernetes objects on this EKS cluster"For information on the preceding error, see Resolve the Kubernetes object access error in Amazon EKS.Error: "Changing the cluster creator IAM to another user/role"After you create a cluster, you can't change the cluster creator IAM to another user because you can't configure a cluster creator IAM.Network issuesError: "Unable to connect to the server: dial tcp 172.xx.xx.xx.xx:443: i/o timeout"If you receive this error, then confirm that the security groups are permitting traffic from the sender's source IP address.Error: "Unable to connect to the server: x509: certificate is valid for *.example.com , example.com , not https://xxx.gr7.us-east-1.eks.amazonaws.com"If you receive this error, then verify that the proxy settings are correct.KUBECONFIG issuesError: "The connection to the server localhost:8080 was refused"The preceding error occurs when the kubeconfig file is missing. The kubeconfig file is located in ~/.kube/config, and kubectl requires the file. This file contains cluster credentials that are required to connect to the cluster API server. If kubectl can't find this file, then it tries to connect to the default address (localhost:8080).Error: "Kubernetes configuration file is group-readable"The preceding error occurs when the permissions for the kubeconfig file are incorrect. To resolve this issue, run the following command:chmod o-r ~/.kube/configchmod g-r ~/.kube/configAWS IAM Identity Center (successor to AWS Single Sign-On) configuration issuesImportant: Remove /aws-reserved/sso.amazonaws.com/ from the rolearn URL. If you don't, then you can't authorize as a valid user.Assign user groups to an IAM permissions policy1.    Open the IAM Identity Center console.2.    Choose the AWS Accounts tab, and then choose AWS account to assign users.3.    Choose Assign Users.4.    Search for the user groups, and then choose Next: Permission sets.5.    Choose Create new permission set, and then choose Create a custom permission set.6.    Give the permission set a name, and then select the Create a custom permissions policy check box.7.    Copy the following permissions policy, and then paste it into the window:{"Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Action": "sts:AssumeRole",      "Resource": "*"    }  ]}8.    Choose Create.Configure role permissions with Kubernetes RBACTo configure role permissions with Kubernetes RBAC, use the following manifest to create a RBAC role:apiVersion: rbac.authorization.k8s.io/v1 kind: Rolemetadata:    name: <example name of the RBAC group>    namespace: <example name of namespace> rules: - apiGroups: [""]    resources: ["services", "endpoints", "pods", "deployments", "ingress"]    verbs: ["get", "list", "watch"]Modify the IAM authenticator ConfigMap1.    Run the following command to capture the IAM role of the IAM Identity Center user group that contains the desired user's data:aws iam list-roles | grep Arn2.    Run the following h command to modify the authenticator ConfigMap:kubectl edit configmap aws-auth --namespace kube-system3.    Add the following attributes to the ConfigMap under mapRoles:- rolearn: <example arn of the AWS SSO IAM role> username: <example preferred username> groups:    - <example name of the RBAC group>Important: Remove /aws-reserved/sso.amazonaws.com/ from the rolearn URL. If you don't, then you can't authorize as a valid user.4.    Update your kubeconfig file by running the following command:aws eks update-kubeconfig —-name <example eks cluster>  —-region <example region>5.    Log in with the IAM Identity Center user name, and then run the kubectl commands.Related informationDefault roles and role bindingsControlling access to EKS clustersFollow"


Question: How can I resolve API throttling or "Rate exceeded" errors for IAM and AWS STS?

"My application is getting an error message similar to the following:"Throttling: Rate exceeded, status code: 400,""

Answer: "My application is getting an error message similar to the following:"Throttling: Rate exceeded, status code: 400,"Short descriptionAPI calls from the AWS Management Console, the AWS Command Line Interface (AWS CLI), and applications contribute to a maximum rate limit for your AWS account.Note: The AWS service rate limits can't be increased.ResolutionFollow these best practices to avoid throttling errors.Implement exponential backoff in your application's code. Exponential backoff allows longer waits each time an API call to AWS is throttled. Depending on the application, the maximum number of delays and the maximum number of retries can vary.Note: AWS SDK implements automatic retry logic and exponential backoff algorithms.Some applications can implement caching to lower the rate of API calls. For example, if your application calls the API call AssumeRole for a cross-account workflow, the temporary credentials you received can be stored and reused for multiple cross-account calls. This means that you don't need to make a new AssumeRole call for each cross-account API call made.If your application is calling AssumeRole and caching the credentials, you can check the maximum session duration of the role's temporary credentials. Lengthening the duration of the temporary credentials makes sure that you don't need to call AssumeRole as often.Spread your API calls over a longer period of time instead of calling the APIs all at once. For example, applications that have a daily job calling SimulatePrincipalPolicy or GenerateServiceLastAccessedDetails to audit permissions for AWS Identity and Access Management (IAM) users and roles. You can stagger the API calls instead of running them at the same time.For applications that dynamically change IAM policy permissions using API calls like CreatePolicyVersion, consider another method. For example, you can use session policies during IAM role assumption.For AWS Security Token Service (AWS STS) throttling errors, consider using Regional STS endpoints instead of sending all AWS STS calls to the global endpoint. Each endpoint has a separate throttling limit. Using Regional AWS STS endpoints can provide applications a faster response time on the AWS STS API calls.If you're not sure which IAM user or role in your AWS account is making a large amount of API calls, use AWS CloudTrail to view Event history.You can also use Amazon Athena to run SQL queries and filter CloudTrail logs. For instructions, see How can I find which API call is causing the "Rate exceeded" error?Because AWS accounts have separate throttling limits, consider spreading the workloads across multiple accounts using AWS Organizations. Creating new AWS accounts are at no additional cost and Organizations provides consolidated billing. Using Service control policies (SCPs) allow you to control the maximum permissions of IAM users and roles across an AWS account. For more information, see Manage accounts through AWS Organizations and How do I get started with AWS Organizations?Related informationHow do I automatically create tables in Amazon Athena to search through AWS CloudTrail logs?Follow"


Question: How can I troubleshoot issues with my weighted routing policy in Route 53?

I get unexpected results when testing the DNS resolution for a weighted routing policy in Amazon Route 53.

Answer: "I get unexpected results when testing the DNS resolution for a weighted routing policy in Amazon Route 53.Short descriptionSuppose that you created a text (TXT) record with the name "weighted.awsexampledomain.com". The record has a Time to Live (TTL) of 300 seconds, and has weights configured as follows:NameTypeTTLValuesWeightHealth check statusweighted.awsexampledomain.com.TXT300"Record with Weight 0"Weight=0Health check associatedweighted.awsexampledomain.com.TXT300"Record with Weight 20"Weight=20Health check associatedweighted.awsexampledomain.com.TXT300"Record with Weight 50"Weight=50Health check associatedweighted.awsexampledomain.com.TXT300"Record with Weight 70"Weight=70Health check associatedThis configuration is referenced in the following examples.ResolutionNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you're using the most recent AWS CLI version.Test your weighted routing policy to identify the issueSend multiple (over 10,000) queries to test your weighted routing policy. Test the DNS resolution from multiple locations or directly query the authoritative name servers to understand the policy. Use the following scripts to send multiple DNS queries for your domain name.Send DNS queries using the recursive resolver:#!/bin/bashfor i in {1..10000}dodomain=$(dig <domain-name> <type> @RecursiveResolver_IP +short)echo -e  "$domain" >> RecursiveResolver_results.txtdoneSend DNS queries directly to the authoritative name servers:#!/bin/bashfor i in {1..10000}dodomain=$(dig <domain-name> <type> @AuthoritativeNameserver_IP +short)echo -e  "$domain" >> AuthoritativeNameServer_results.txtdoneExample output using the awk tool in the AWS CLI:$ for i in {1..10000}; do domain=$(dig weighted.awsexampledomain.com. TXT @172.16.173.64 +short); echo -e  "$domain" >> RecursiveResolver_results.txt; done$ awk ' " " ' RecursiveResolver_results.txt | sort | uniq -c1344 "Record with Weight 20"3780 "Record with Weight 50"4876 "Record with Weight 70"Use your test results to troubleshoot your specific issueIssue: Endpoint resources of the weighted records aren't receiving the expected traffic ratio.Route 53 sends traffic to resources based on the weight assigned to the record as a proportion of the total weight for all records. Intermediate DNS resolvers cache the DNS responses for the duration of the record TTL. Clients are directed to only specific endpoints for the duration due to the cached response.ExampleYou query against the caching DNS resolver 192.168.1.2:$ for i in {1..10000}; do domain=$(dig weighted.awsexampledomain.com. TXT @192.168.1.2 +short); echo -e  "$domain" >> CachingResolver_results.txt; done$ awk ' " " ' CachingResolver_results.txt | sort | uniq -c3561 "Record with Weight 20"1256 "Record with Weight 50"5183 "Record with Weight 70"Notice that the preceding results aren't as expected because the cache at the recursive DNS resolver.Issue: Some weighted records aren't returned.If you associate health checks to a resource record set, then Route 53 responds with the record only if the associated health check is successful. For more information, see How Amazon Route 53 determines whether a health check is healthy.If an RRSet in a policy doesn't have an attached health check, then it's always considered healthy. It's also included in the possible responses to DNS queries. Records that fail health checks aren't returned. Check the health check configuration, and be sure that it's reported as healthy.If you use "Evaluate Target Health" with the resource record set, then Route 53 relies on the health check reported by the end resource. For more information, see Why is my alias record pointing to an Application Load Balancer marked as unhealthy when I’m using “Evaluate Target Health"?ExampleSome health checks are failing:NameTypeTTLValuesWeightHealth check statusweighted.awsexampledomain.com.TXT300"Record with Weight 0"Weight=0Health Check Successweighted.awsexampledomain.com.TXT300"Record with Weight 20"Weight=20Health Check Successweighted.awsexampledomain.com.TXT300"Record with Weight 50"Weight=50Health Check Failweighted.awsexampledomain.com.TXT300"Record with Weight 70"Weight=70Health Check Success$ for i in {1..10000}; do domain=$(dig weighted.awsexampledomain.com. TXT @192.168.1.2 +short); echo -e  "$domain" >> HealthCheck_results.txt; done$ awk ' " " ' HealthCheck_results.txt | sort | uniq -c3602 "Record with Weight 20"6398 "Record with Weight 70"In this example, the "Record with Weight 50" isn't returned by Route 53 because its health check is failing.Issue: All weighted records are unhealthy.Even if none of the records in a group of records are healthy, Route 53 must still provide a response to the DNS queries. However, there's no basis for choosing one record over another. In this case, Route 53 considers all the records in the group to be healthy. One record is selected based on the routing policy and the values that you specify for each record.ExampleNameTypeTTLValuesWeightHealth check statusweighted.awsexampledomain.com.TXT300"Record with Weight 0"Weight=0Health Check Failweighted.awsexampledomain.com.TXT300"Record with Weight 20"Weight=20Health Check Failweighted.awsexampledomain.com.TXT300"Record with Weight 50"Weight=50Health Check Failweighted.awsexampledomain.com.TXT300"Record with Weight 70"Weight=70Health Check Fail$ for i in {1..10000}; do domain=$(dig weighted.awsexampledomain.com. TXT @205.251.194.16 +short); echo -e  "$domain" >> All_UnHealthy_results.txt; done$ awk ' " " ' All_UnHealthy_results.txt | sort | uniq -c1446 "Record with Weight 20"3554 "Record with Weight 50"5000 "Record with Weight 70"In this example, Route 53 considered all records healthy (Fail Open). Route 53 responded to the DNS requests based on the configured proportions. "Record with Weight 0" isn't returned because its weight is zero.Note: If you set nonzero weights to some records and zero weights to others, then health checks work the same as when all records have nonzero weights. However, there are a few exceptions:Route 53 initially considers only the healthy nonzero weighted records, if any.If all nonzero records are unhealthy, then Route 53 considers the healthy zero weighted records.ExampleNameTypeTTLValuesWeightHealth Check Statusweighted.awsexampledomain.com.TXT300"Record with Weight 0"Weight=0Health Check Passweighted.awsexampledomain.com.TXT300"Record with Weight 20"Weight=20Health Check Passweighted.awsexampledomain.com.TXT300"Record with Weight 50"Weight=50Health Check Failweighted.awsexampledomain.com.TXT300"Record with Weight 70"Weight=70Health Check Fail$ for i in {1..10000}; do domain=$(dig weighted.awsexampledomain.com. TXT @192.168.1.2 +short); echo -e  "$domain" >> HealthCheck_results.txt; done$ awk ' " " ' HealthCheck_results.txt | sort | uniq -c10000 "Record with Weight 20"In this example, Route 53 doesn't consider the record with weight 0. Unless all weighted records are unhealthy, Route 53 doesn't return the zero-weighted records.If you set an equal weight for all records in a group, then traffic is routed to all healthy resources with equal probability. If you set "Weight" to zero for all records in a group, then traffic is routed to all healthy resources with equal probability.Related informationChoosing a routing policyHow Amazon Route 53 chooses records when health checking is configuredFollow"


Question: What are the best practices to follow when migrating a source RDS MySQL database to a target RDS MySQL database using AWS DMS?

I have a MySQL database that I want to migrate to an Amazon Relational Database Service (Amazon RDS) for MySQL database using AWS Database Migration Service (AWS DMS). What best practices can I use to optimize migration between a source MySQL database and a target MySQL database?

Answer: "I have a MySQL database that I want to migrate to an Amazon Relational Database Service (Amazon RDS) for MySQL database using AWS Database Migration Service (AWS DMS). What best practices can I use to optimize migration between a source MySQL database and a target MySQL database?Short descriptionUsing AWS DMS, you can migrate data from a source data store to a target data store. These two data stores are called endpoints. You can migrate between source and target endpoints that use the same database engine, such as from one MySQL database to another MySQL database.Although AWS DMS creates the target schema objects, it creates only the minimum objects that it needs for data to be effectively migrated from the source. So, AWS DMS creates tables, primary keys, and in some cases unique indexes, but it doesn't create objects such as secondary indexes, non-primary key constraints, and data defaults. For more information on what AWS DMS migrates, see High-level view of AWS DMS.Pre-create the tables on the target database before migrationTo preserve the default data definitions, pre-create the tables on the target database before migration. Use one of these approaches, depending on the type of migration you're performing:For homogeneous migrations such as MySQL to MySQL, use the native database engine utilities such as mysqldump to take an export of the table definitions. Then, import these table definitions into the target without the data. After the table definitions are created, use the AWS DMS task with target table preparation mode set to TRUNCATE_BEFORE_LOAD to load the data.For migrations across different database engines, use the AWS Schema Conversion Tool (AWS SCT). You can also use this method for homogeneous databases. The AWS SCT connects to your source and target databases, and then converts the existing database schema from one database engine to another. You can use the AWS SCT to pre-create tables on the target database with the default data definitions intact. Then, use the AWS DMS task with the target table preparation mode set to TRUNCATE_BEFORE_LOAD to load the data. For more information, see Converting your schema by using AWS SCT.ResolutionFollow the best practices for MySQL to MySQL AWS DMS migrationUse these best practices when you migrate data from a MySQL source database to a MySQL target database.Turn off backups and database-specific logs (such as bin, general, and audit) on the target database during migration. If you need to, you can turn them on again to troubleshoot issues.Turn off triggers, other cron jobs, and event schedulers on the target database during migration.Avoid using Multi-AZ on the target Amazon RDS database when performing AWS DMS migration.Avoid applying any other external client traffic to the target database when performing migration.Provision your AWS DMS replication instance, source, and the target databases with the required CPU, memory, storage, and IOPS to avoid resource contention during migration.Configure the source database with the prerequisites for using AWS DMS change data capture (CDC) before you start migration.Use optimized LOB settings such as limited LOB and inline LOB for migration.If the source database contains many tables with a heavy workload, split the tables among multiple tasks. Split the tables based on their size on the source database, the application traffics pattern, and the presence of LOB columns. If the table has many LOB (TEXT or JSON) columns with high write traffics on the source, then create a separate task for the table. Transactional consistency is maintained within a task, so it's important that tables in separate tasks don't participate in common transactions.Use the parallel full load mechanism for heavy source tables to reduce migration time. For more information, see Using parallel load for selected tables, views, and collections.Turn off foreign key constraints on the target table during full load migration.Add secondary index on the target database before starting the CDC phase of replication.The Amazon RDS primary user doesn't have drop and recreate privileges on the default schema tables. So, avoid migrating default database or schema tables from the source using AWS DMS.Review the documentation on Using AWS DMS to migrate data from MySQL to MySQL for information on which types of data that AWS DMS can migrate successfully.Test your workload using the default transactional CDC apply before you use the batch apply CDC method. For more information, see How can I use the DMS batch apply feature to improve CDC replication performance?Test the migration using the same production data on any other QA/DEV database environment before starting the production migration. Make sure to use the same AWS DMS configuration when you do the production migration.For more information, see Improving the performance of an AWS DMS migration.Use the recommended configuration and methods on your source and target databasesPre-create the table DDL on the target MySQL/PostgreSQL databases manually. Then, create an AWS DMS task with target preparation mode set to DO_DOTHING”/"TRUNCATE to migrate only the data.Run this command to create a dump without data from the source MySQL database:mysqldump -h yourhostnameorIP -u root -p --no-data --skip-triggers --single-transaction --dbname > schema.sqlThis command dumps the DDL structure from the source without any data.Next, run this command to restore the DDL structure on the target:mysql -u user -p -h yourhostnameorIP  database_name < schema.sqlOr, you can allow AWS DMS to create the tables on the target using the DROP AND CREATE target preparation mode. Then, skip to step 3 to alter the table and add missing objects such as secondary indexes before you resume the task for the CDC phase.Note: By default, AWS DMS creates the table on the target with only the primary key or the unique key. It doesn't migrate any other objects to the target MySQL database.During the full load, AWS DMS doesn't identify the foreign key relational tables. It loads the data randomly, so the table load can fail if the target database has a foreign key check turned on. Use this extra connection attribute (ECA) on the target MySQL endpoint to turn off foreign key checks for this AWS DMS session.initstmt=SET FOREIGN_KEY_CHECKS=0;For more information, see Extra connection attributes when using a MySQL-compatible database as a target for AWS DMS.In the JSON settings, set stop task before applying cached changes to true, and stop task after applying cached changes to true."FullLoadSettings": {    "TargetTablePrepMode": "TRUNCATE_BEFORE_LOAD"    "CreatePkAfterFullLoad": false,    "TransactionConsistencyTimeout": 600,    "MaxFullLoadSubTasks": 8,    "StopTaskCachedChangesNotApplied": true,   <--- set this to true    "StopTaskCachedChangesApplied": true,    <--- set this to true    "CommitRate": 50000,}After full load is complete, and before it applies cached changes, the task stops. While the task is stopped, create primary key indexes and secondary indexes on the target.Next, resume the task because the task stops again after it applies cached changes. Then, verify the migrated data by using AWS DMS validation output or manual verification before resuming the task again for the CDC replication phase. By completing this step, you can identify any issues and address them before resuming for CDC replication.4.    In the Task full load settings, tune the commitRate setting to speed up the data extraction rate from the source. The default value is 10000, so tune this setting when you are migrating a large amount of data from the source table.CommitRate=50000Note: Changing commitRate to a higher value could affect performance, so make sure to monitor and have enough memory in the replication instance.5.    Add this ECA on the target endpoint to specify the maximum size (in KB) of any .csv file used to transfer data to the target MySQL. The default value is 32,768 KB (32 MB), and valid values range from 1–1,048,576 KB (up to 1.1 GB).maxFileSize=250000;Note: When you use a target instance such as MySQL, Aurora or MariaDB for full load, use this option to allow AWS DMS to create a .csv file in the background to load the data into the target instance. Use a value between 32 MB and 1 GB. But, also consider how much your target instance can handle. If you have multiple tasks loading 1 GB of .csv file, this can cause overhead on your target instance. Make sure that you have an instance with high computing power at the target.6.    Use the limited LOB or inline LOB settings for better performance.Limited LOB mode: When using Limited LOB mode, you specify the maximum size of LOB column data. This allows AWS DMS to pre-allocate resources, and then apply LOB in bulk. If the size of the LOB columns exceeds the size that you specified in the task, AWS DMS truncates the data. AWS DMS then sends warnings to the AWS DMS log file. Using Limited LOB mode improves performance—however, before you run the task, you must identify the maximum LOB size of the data on the source. Then, specify the Max LOB size parameter. It's a best practice to make sure that you have enough memory allocated to the replication instance to handle the task.Inline LOB mode: When using Inline LOB mode, you can migrate LOBs without truncating data or slowing your task performance, by replicating both small and large LOBs. First, specify a value for the InlineLobMaxSize parameter, which is available only when Full LOB mode is set to true. The AWS DMS task transfers the small LOBs inline, which is more efficient. Then, AWS DMS migrates LOBs that are larger than the specified size in Full LOB mode by performing a lookup from the source table. Note, however, that Inline LOB mode works only during the full load phase.Note: You must set InlineLobMaxSize when you specify the task settings for your task.Run these queries to check the LOB size, and then populate the Max LOB size.List the tables that have LOB columns:select tab.table_name,count(*) as columnsfrom information_schema.tables as tabinner join information_schema.columns as colon col.table_schema = tab.table_schemaand col.table_name = tab.table_nameand col.data_type in ('blob', 'mediumblob', 'longblob','text', 'mediumtext', 'longtext')where tab.table_schema = 'your database name'.  <---- enter database name hereand tab.table_type = 'BASE TABLE'group by tab.table_nameorder by tab.table_name;Check the size of the LOB column:Select (max(length (<COL_NAME>))/(1024)) as “size in KB” from <TABLE_NAME>;Check the size of the LOB columns for all tables, and then populate the maximum size in Max LOB size (K).Using use the Max LOB size (K) option with a value greater than 63 KB affects the performance of a full load configured to run in limited LOB mode. During a full load, AWS DMS allocates memory by multiplying the Max LOB size (k) value by the commit rate. Then, the product is multiplied by the number of LOB columns.When AWS DMS can't pre-allocate that memory, AWS DMS starts consuming SWAP memory. This affects the performance of a full load. So, if you experience performance issues when using limited LOB mode, decrease the commit rate until you achieve an acceptable level of performance. Or, consider using inline LOB mode for supported endpoints after first checking the LOB distribution for the table.For more information, see Setting LOB support for source databases in an AWS DMS task.Related informationMigrate from MySQL to Amazon RDS with AWS DMSDatabase migration step-by-step walkthroughsFollow"


Question: How can I set up alerts to see when an IAM access key is used?

I want to set up notifications to see when a specific AWS Identity and Access Management (IAM) credential or access key is used.

Answer: "I want to set up notifications to see when a specific AWS Identity and Access Management (IAM) credential or access key is used.ResolutionThere are no predefined rules to track and send notifications about the use of IAM credentials. However, you can use a custom rule that combines AWS CloudTrail and Amazon EventBridge. This lets you send a notification to an Amazon Simple Notification Service (Amazon SNS) topic or Amazon Simple Queue Service (Amazon SQS) queue.EventBridge rules are represented as JSON objects. A rule has a simple match or no match logic that applies to events. Based on the structure of events, you can build custom patterns for the specific criteria that you want to match.The following example rule tracks a single access key in the same AWS Region where the rule is configured.Important:You must have an active trail to send events for EventBridge to invoke notifications to your SNS topic or SQS queue.Your trail's management events must be configured as Write-only or All. Trail management events that are configured as Read-only don't invoke the EventBridge rule. For more information, see Read and write events, Events from AWS services, and CloudTrail supported services and integrations.1.    Open the EventBridge console, and then choose Rules.2.    Choose Create rule.3.    Enter a Name for the rule. You can optionally enter a Description. Then, choose Next.4.    For Event source, choose Other.5.    For Creation method, choose Custom pattern (JSON editor).6.    For Event pattern, enter a JSON template that's similar to the following:Note: You can modify this template to track notifications for a range of criteria, such as access keys, login types, or specific identities.{    "detail-type": [        "AWS API Call via CloudTrail"    ],    "detail": {        "userIdentity": {            "accessKeyId": [                "AKIAIOSFODNN7EXAMPLE"            ]        }    }}7.    Choose Next.8.    For Target types, choose AWS service. Then, complete the following fields:For Select a target, select SNS topic or SQS queue.For Topic, select the topic that you want to respond to the event. Then, choose Next.9.    (Optional) Choose tags for your rule, if desired.10.    Choose Next to review your rule. Then, choose Create rule.Related informationAmazon EventBridge event patternsGetting credential reports for your AWS accountFollow"


Question: Why am I receiving errors when deleting a static IP address using the Amazon Lightsail console?

I'm receiving the error "The specified Static IP address cannot be released from your account. A reverse DNS record may be associated with the Static IP address." when deleting a static IP address from my Amazon Lightsail console. How do I resolve this issue?

Answer: "I'm receiving the error "The specified Static IP address cannot be released from your account. A reverse DNS record may be associated with the Static IP address." when deleting a static IP address from my Amazon Lightsail console. How do I resolve this issue?Short descriptionYou might receive the specified Static IP address cannot be released error message when a reverse Domain Name System (rDNS) record was previously created for your static IP address and the rDNS entry isn't removed.To confirm if the static IP address has rDNS mapping to the domain, run the following command on the Terminal or Powershell:$ nslookup -type=ptr 8.8.8.8Note: Replace IP address 8.8.8.8 with your static IP address.If the rDNS record doesn't end with "compute.amazonaws.com" but instead ends with a custom record of your domain, then you must request for rDNS removal.ResolutionTo resolve the issue, submit a request to remove the rDNS record for the static IP address.Open the Request to remove email sending limitations form.Complete the form using the following information:Email Address: Your email address.Use Case Description: Provide your specific use case for requesting rDNS removal.Elastic IP address: Enter IP address here.Reverse DNS record: Enter "Remove rDNS record".Note: You have the option to enter up to 100 Elastic IP addresses.Choose Submit.Note: rDNS removal might take a few hours to propagate through the system.You receive an email with the Request ID after submitting the request form. It might take up to 48 hours to process your request. If your request is approved, then you receive an email to notify you that the rDNS record is removed. After you receive confirmation that the associated rDNS record is removed, you can delete the static IP address from the Lightsail console. If you don't receive an update within 48 hours after submitting the request, then reply to the initial email that you received.Follow"


Question: How can I audit deleted or missing objects from my Amazon S3 bucket?

There's an object or file that's missing from my Amazon Simple Storage Service (Amazon S3) bucket. Where can I find information about how the object or file was deleted? How can I prevent future accidental deletions?

Answer: "There's an object or file that's missing from my Amazon Simple Storage Service (Amazon S3) bucket. Where can I find information about how the object or file was deleted? How can I prevent future accidental deletions?ResolutionTo find out how an S3 object was deleted, you can review either server access logs or AWS CloudTrail logs.Note: Logging must be enabled on the bucket before the deletion event occurs. You receive logs only for events that occurred after logging was enabled.Server access logs track S3 operations performed manually or as part of a lifecycle configuration. To enable server access logging, see How do I enable server access logging for an S3 bucket? For more information on how to analyze server access logs, see How do I analyze my Amazon S3 server access logs using Athena?CloudTrail logs can track object-level data events in an S3 bucket, such as GetObject, DeleteObject, and PutObject. To enable CloudTrail logs for object-level events, see How do I enable object-level logging for an S3 bucket with AWS CloudTrail data events? For more information on how to find specific events, see I enabled object-level logging for my Amazon S3 bucket. Where can I find the events in the CloudTrail event history?Note: By default, CloudTrail records bucket-level events. To get logs for object-level operations like GetObject, DeleteObject, and PutObject, you must configure object-level logging. Object-level logging incurs additional charges, so be sure to review the pricing for CloudTrail data events.To prevent or mitigate future accidental deletions, consider the following features:Enable versioning to keep historical versions of an object.Enable Cross-Region Replication of objects.Enable MFA delete to require multi-factor authentication (MFA) when deleting an object version.Follow"


Question: How do I troubleshoot connectivity issues that I'm experiencing while using an Amazon VPC?

I'm unable to connect to my destination server using an Amazon Virtual Private Cloud (Amazon VPC) resource as the source.

Answer: "I'm unable to connect to my destination server using an Amazon Virtual Private Cloud (Amazon VPC) resource as the source.ResolutionTo troubleshoot VPC connectivity issues, use the AWSSupport-ConnectivityTroubleshooter automation document to check for common issues with:Security group configurationsNetwork access control list (network ACL) configurationsRoute table configurationsConfirm that you have the required permissions to run the automation documentThe following AWS Identity and Access Management (IAM) permissions are required to run the automation document:ec2:DescribeNetworkInterfacesec2:DescribeRouteTablesec2:DescribeSecurityGroupsec2:DescribeNetworkAclsec2:DescribeNatGatewaysec2:DescribeVpcPeeringConnectionsRun the automation documentFrom the AWS Management Console:Open the document in the AWS Systems Manager console. Be sure to open the document in the Region where your resources are located.For SourceIP, enter the private IP address of the VPC resource.For DestinationIP, enter the destination server IP address.For DestinationPort, enter the destination server port.Choose Execute.Monitor the progress of the document's execution. If the document status is Success, the automation didn't find any misconfigurations. If the document status is Failed, check the step that failed for details to resolve the issue.From the AWS Command Line Interface (AWS CLI):Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.For example, to diagnose connectivity issues from 172.31.2.7 to 172.31.2.8 on port 443 in an Amazon VPC:aws ssm start-automation-execution --document-name "AWSSupport-ConnectivityTroubleshooter" --parameters "SourceIP=172.31.2.7,DestinationIP=172.31.2.8,DestinationPort=443" --region <region>Follow"


Question: How can I allocate memory to tasks in Amazon ECS?

I want to use Amazon Elastic Container Service (Amazon ECS) to allocate memory to tasks.

Answer: "I want to use Amazon Elastic Container Service (Amazon ECS) to allocate memory to tasks.Short descriptionIn Amazon ECS, memory can be defined at both the task level and at each container level. Memory defined at the task level is the hard limit of memory for the task. At the container level, there are two parameters for allocating memory to tasks: memoryReservation (a soft limit) and memory (a hard limit). For tasks that are hosted on Amazon EC2 instances, the task level memory field is optional, and any value can be used. If a task-level memory value is specified, then the container-level memory value is optional. The value for each parameter is subtracted from the available memory units of an Amazon ECS container instance when a task is running. The calculation is based on the soft limit, hard limit, or task-level memory of a task definition. For more information, see Cluster reservation.Note: The memory and memoryReservation parameters are set as the container definition parameters of an Amazon ECS task definition. If you specify a value for both container-level memory and memoryReservation, then memory must be greater than memoryReservation. If you specify memoryReservation, then that value is subtracted from the available memory resources for the container instance where the container is placed. Otherwise, the value of memory is used. For more information, see Memory.ResolutionBefore you start, check to see that you have an Amazon ECS cluster that includes an Amazon Elastic Compute Cloud (Amazon EC2) instance. For more information on creating a cluster, see Creating a cluster using the classic console. For more information on configuring the cluster and container instance, see Container Instance Memory Management.View the memory allocations of a container instanceOpen the Amazon ECS console.In the navigation pane, choose Clusters.Choose the cluster that you created.Choose the ECS Instances view, and then choose the container instance included with the cluster that you created from the Container Instance column.Note: The Details pane shows that the memory in the Available column is equal to the memory in the Registered column.For statistics on the resource usage of the instance, connect to the instance using SSH, and then run the docker stats command.Create a task definition with a soft limitFrom the Amazon ECS console, in the navigation pane, choose Task Definitions.Choose Create new Task Definition.For the launch type, choose EC2, and then choose Next step.For Task Definition Name, enter a name.In the Container Definitions section, choose Add container.For Container name, enter a name.For Image, enter nginx or the appropriate Docker image for your environment.For Memory Limits (MiB), choose Soft limit, and then enter 700.Choose Add, and then choose Create.Run the task definition with a soft limitFrom the Amazon ECS console, in the navigation pane, choose Clusters, and then choose the cluster that you created.Choose the Tasks view, and then choose Run new Task.Choose Launch Type as EC2, choose the task definition that you created with soft limit, and then choose Run Task. Note: Task Definition and Cluster can be prepopulated with the name of the task definition and cluster that you created earlier if you are using ECS for the first time.When the Last status column of the task with a soft limit shows as RUNNING, move to next step.Note: To update the status of the task to RUNNING, refresh the page.Choose the ECS Instances view, and then choose the instance from the Container Instance column.Note: The Details pane shows that the memory in the Available column is less than the memory in the Registered column.For statistics on the resource usage of the instance, connect to the instance using SSH, and then run the docker stats command.Choose Clusters from the navigation pane, and then choose the cluster.Choose the Tasks view, select the task with a soft limit, and then choose Stop.Choose the ECS Instances view, and then choose the instance from the Container Instance column.Note: The Details pane shows that the memory in the Available column is equal to the memory in the Registered column.Create a new revision of a task definition with a hard limitFrom the Amazon ECS console, in the navigation pane, choose Task Definitions.Select the task definition that you created with a soft limit, and then choose Create new revision.In the Container Definitions section, in the Container Name column, choose the container that you added for the task definition with a soft limit.For Memory Limits (MiB), choose Hard limit, and then enter 1000.Choose Update, and then choose Create.Run the revised task definition with a hard limitFrom the Amazon ECS console, in the navigation pane, choose Clusters, and then choose the cluster that you created.Choose the Tasks view, and then choose Run new Task.Choose Launch Type as EC2For Task Definition, choose the task definition with a hard limit that you created, and then choose Run Task.When the Last status column of the revised task with a hard limit shows as RUNNING, move to next step.Note: To update the status of the task to RUNNING, refresh the page.Choose the ECS Instances view, and then choose the instance from the Container Instance column.Note: The Details pane shows that available memory in the Available column is less than the memory in the Registered column.For statistics on the resource usage of the instance, connect to the instance using SSH, and then run the docker stats command.Choose Clusters from the navigation pane, and then choose the cluster.Choose the Tasks view, select the task with a hard limit, and then choose Stop.Choose the ECS Instances view, and then choose the instance from the Container Instance column.Note: The Details pane shows that the memory in the Available column is equal to the memory in the Registered column.Create a new revision of a task definition with both a soft limit and a hard limitFrom the Amazon ECS console, in the navigation pane, choose Task Definitions.Select the task definition that you created with a hard limit, and then choose Create new revision.In the Container Definitions section, in the Container Name column, choose the container that you added for the task definition with a hard limit.For Memory Limits (MiB), choose Soft limit, and then enter 700.Choose Add Hard limit, and then enter 1200.Choose Update, and then choose Create.Run the revised task definition with both a soft limit and a hard limitFrom the Amazon ECS console, in the navigation pane, choose Clusters, and then choose the cluster that you created.Choose the Tasks view, and then choose Run new Task.Choose Launch Type as EC2For Task Definition, choose the task definition that you created with both a soft limit and a hard limit, and then choose Run Task.When the Last status column of the task shows as RUNNING, move to next step.Note: To update the status of the task to RUNNING, refresh the page.Choose the ECS Instances view, and then choose the instance from the Container Instance column.Note: The Details pane shows that the memory in the Available column is less than the memory in the Registered column.For statistics on the resource usage of the instance, connect to the instance using SSH, and then run the docker stats command.Choose Clusters from the navigation pane, and then choose the cluster.Choose the Tasks view, select the task with both a soft limit and a hard limit, and then choose Stop.Choose the ECS Instances view, and then choose the instance from the Container Instance column.Note: The Details pane shows that the memory in the Available column is equal to the memory in the Registered column.Create a new revision of a task definition with Task Level Memory limitFrom the Amazon ECS console, in the navigation pane, choose Task Definitions.Select the task definition that you created with a hard and soft limit, and then choose Create new revision.Under the Task Size section, for Task memory (MiB) enter 1000In the Container Definitions section, in the Container Name column, choose the container that you added for the task definition with a hard and soft limit.For Memory Limits (MiB), remove Soft limit, by choosing the x icon on the right sideNext for Hard limit, remove the value 1200 by selecting it and deleting it.Choose Update, and then choose Create.Run the revised task definition with Task Level Memory limitFrom the Amazon ECS console, in the navigation pane, choose Clusters, and then choose the cluster that you created.Choose the Tasks view, and then choose Run new Task.Choose Launch Type as EC2For Task Definition, choose the task definition that you created with Task Level memory, and then choose Run Task.When the Last status column of the task shows as RUNNING, move to next step.Note: To update the status of the task to RUNNING, refresh the page.Choose the ECS Instances view, and then choose the instance from the Container Instance column.Note: The Details pane shows that the memory in the Available column is less than the memory in the Registered column.For statistics on the resource usage of the instance, connect to the instance using SSH, and then run the docker stats command.Note: You might observe that the memory limit shown by the docker stats command might not be 1000 MiB for the container. This is because the Task Level memory is managed by ECS Agent and not by docker daemon.Choose Clusters from the navigation pane, and then choose the cluster.Choose the Tasks view, select the task with Task level memory, and then choose Stop.Choose the ECS Instances view, and then choose the instance from the Container Instance column.Note: The Details pane shows that the memory in the Available column is equal to the memory in the Registered column.Related informationAmazon ECS CloudWatch metricsAmazon EC2 Instance typesLimit a container's access to memoryTask sizeFollow"


Question: Why did my Spark job in Amazon EMR fail?

My Apache Spark job in Amazon EMR failed.

Answer: "My Apache Spark job in Amazon EMR failed.ResolutionApplication failuresERROR ShuffleBlockFetcherIterator: Failed to get block(s) from ip-192-168-14-250.us-east-2.compute.internal:7337org.apache.spark.network .client.ChunkFetchFailureException: Failure while fetching StreamChunkId[streamId=842490577174,chunkIndex=0]: java.lang.RuntimeException: Executor is not registered (appId=application_1622819239076_0367, execId=661)This issue might occur when the executor worker node in Amazon EMR is in an unhealthy state. When disk utilization for a worker node exceeds the 90% utilization threshold, the YARN NodeManager health service reports the node as UNHEALTHY. Unhealthy nodes are included in Amazon EMR deny lists. In addition, YARN containers aren't allocated to those nodes.To troubleshoot this issue, do the following:Review the resource manager logs from the EMR cluster master node for unhealthy worker nodes. For more information, see How do I resolve ExecutorLostFailure "Slave lost" errors in Spark on Amazon EMR? and review the High disk utilization section.Verify impacted node disk space utilization, review files consuming disk space, and perform data recovery to return nodes to a healthy state. For more information, see Why is the core node in my Amazon EMR cluster running out of disk space?ERROR [Executor task launch worker for task 631836] o.a.s.e.Executor:Exception in task 24.0 in stage 13028.0 (TID 631836) java.util.NoSuchElementException: None.getThis error occurs when there is a problem within the application code and the SparkContext initialization.Make sure that there aren't multiple SparkContext jobs active within the same session. According to the Java Virtual Machine (JVM), You can have one active SparkContext at a time. If you want to initialize another SparkContext, then you must stop the active job before creating a new one.Container killed on request. Exit code is 137This exception occurs when a task in a YARN container exceeds the physical memory allocated for that container. This commonly happens when you have shuffle partitions, inconsistent partition sizes, or a large number of executor cores.Review error details in the Spark driver logs to determine the cause of the error. For more information, see How can I access Spark driver logs on an Amazon EMR cluster?The following is an example error from the driver log:ERROR YarnScheduler: Lost executor 19 on ip-10-109-xx-xxx.aws.com : Container from a bad node: container_1658329343444_0018_01_000020 on host: ip-10-109-xx-xxx.aws.com . Exit status: 137.Diagnostics:Container killed on request. Exit code is 137Container exited with a non-zero exit code 137.Killed by external signalExecutor container 'container_1658329343444_0018_01_000020' was killed with exit code 137. To understand the root cause, you can analyze executor container log.# java.lang.OutOfMemoryError: Java heap space# -XX:OnOutOfMemoryError="kill -9 %p"# Executing /bin/sh -c "kill -9 23573"...The preceding error stack trace indicates that there isn't enough available memory on the executor to continue processing data. This error might happen in different job stages in both narrow and wide transformations.To resolve this issue, do one of the following:Increase executor memory.Note: Executor memory includes memory required for executing the tasks plus overhead memory. The sum of these must not be greater than the size of JVM and the YARN maximum container size.Add more Spark partitions.Increase the number of shuffle partitions.Reduce the number of executor cores.For more information, see How do I resolve "Container killed on request. Exit code is 137" errors in Spark on Amazon EMR?Spark jobs are in a hung state and not completingSpark jobs might be in stuck for multiple reasons. For example, if the Spark driver (application master) process is impacted or executor containers are lost.This commonly happens when you have high disk space utilization, or when you use Spot Instances for cluster nodes and the Spot Instance is terminated. For more information, see How do I resolve ExecutorLostFailure "Slave lost" errors in Spark on Amazon EMR?To troubleshoot this issue, do the following:Review Spark application master or driver logs for any exceptions.Validate the YARN node list for any unhealthy nodes. When disk utilization for a core node exceeds the utilization threshold, the YARN Node Manager health service reports the node as UNHEALTHY. Unhealthy nodes are included in Amazon EMR deny lists. In addition, YARN containers aren't allocated to those nodes.Monitor disk space utilization, and configure Amazon Elastic Block Store (Amazon EBS) volumes to keep utilization below 90% for EMR cluster worker nodes.WARN Executor: Issue communicating with driver in heartbeater org.apache.spark.rpc.RpcTimeoutException: Futures timed out after [10000 milliseconds]. This timeout is controlled by spark.executor.heartbeatIntervalSpark executors send heartbeat signals to the Spark driver at intervals specified by the spark.executor.heartbeatInterval property. During long garbage collection pauses, the executor might not send a heartbeat signal. The driver kills executors that fail to send a heartbeat signal for more than the value specified.TimeoutExceptionTimeout exceptions occur when the executor is under memory constraint or facing OOM issues while processing data. This also impacts the garbage collection process, causing further delay.Use one of the following methods to resolve heartbeat timeout errors:Increase executor memory. Also, depending on the application process, repartition your data.Tune garbage collection.Increase the interval for spark.executor.heartbeatInterval.Specify a longer spark.network.timeout period.ExecutorLostFailure "Exit status: -100. Diagnostics: Container released on a *lost* nodeThis error occurs when a core or task node is terminated because of high disk space utilization. The error also occurs when a node becomes unresponsive due to prolonged high CPU utilization or low available memory. For troubleshooting steps, see How can I resolve "Exit status: -100. Diagnostics: Container released on a *lost* node" errors in Amazon EMR?Note: This error might also occur when you use Spot Instances for cluster nodes, and a Spot Instance is terminated. In this scenario, the EMR cluster provisions an On-Demand Instance to replace the terminated Spot Instance. This means that the application might recover on its own. For more information, see Spark enhancements for elasticity and resiliency on Amazon EMR.executor 38: java.sql.SQLException (Network error IOException: Connection timed out (Connection timed out)This issue is related to communication with the SQL database for establishing the socket connection when reading or writing data. Verify that the DB host can receive incoming connections on Port 1433 from your EMR cluster security groups.Also, review the maximum number of parallel database connections configured for the SQL DB and the memory allocation for the DB instance class. Database connections also consume memory. If utilization is high, then review the database configuration and the number of allowed connections. For more information, see Maximum number of database connections.Amazon S3 exceptionsHTTP 503 "Slow Down"HTTP 503 exceptions occur when you exceed the Amazon Simple Storage Service (Amazon S3) request rate for the prefix. A 503 exception doesn't always mean that a failure will occur. However, mitigating the problem can improve your application's performance.For more information, see Why does my Spark or Hive job on Amazon EMR fail with an HTTP 503 "Slow Down" AmazonS3Exception?HTTP 403 "Access Denied"HTTP 403 errors are caused by incorrect or not valid credentials, such as:Credentials or roles that are specified in your application code.The policy that's attached to the Amazon EC2 instance profile role.Amazon Virtual Private Cloud (Amazon VPC) endpoints for Amazon S3.S3 source and destination bucket policies.To resolve 403 errors, be sure that the relevant AWS Identity and Access Management (IAM) role or policy allows access to Amazon S3. For more information, see Why does my Amazon EMR application fail with an HTTP 403 "Access Denied" AmazonS3Exception?HTTP 404 "Not Found"HTTP 404 errors indicate that the application expected to find an object in S3, but at the time of the request, the object wasn't found. Common causes include:Incorrect S3 paths (for example, a mistyped path).The file was moved or deleted by a process outside of the application.An operation that caused eventual consistency problems, such as an overwrite.For more information, see Why does my Amazon EMR application fail with an HTTP 404 "Not Found" AmazonS3Exception?Follow"


Question: Why can't my Amazon EC2 instance connect to the internet using an internet gateway?

"My Amazon Elastic Compute Cloud (Amazon EC2) instance in a public subnet has a public IP address or an internet gateway, but can’t access the internet."

Answer: "My Amazon Elastic Compute Cloud (Amazon EC2) instance in a public subnet has a public IP address or an internet gateway, but can’t access the internet.Short descriptionTo troubleshoot why your Amazon EC2 can't access the internet, do the following:Verify that the EC2 instance meets all prerequisites.Verify that the instance has a public IP address.Verify that a firewall isn't blocking the access.ResolutionVerify that the instance meets all prerequisitesThe instance must meet the following conditions:The route table that's associated with your instance’s subnet has a default route to an internet gateway (0.0.0.0/0).The internet gateway that's associated with the route isn't deleted.The security group that's attached to the instance’s elastic network interface has rules allowing outbound internet traffic (0.0.0.0/0) for your ports and protocols.The network access control list (network ACL) that is associated with the instance's subnet has rules allowing both outbound and inbound traffic to the internet.Verify that the instance has a public IP addressIf the instance in a public subnet doesn't have a public IP address, then the instance isn't accessible outside the virtual private cloud (VPC) where it resides in. This is true even if the instance has an internet gateway.To allow the instance connectivity to the internet, allocate an Elastic IP address, and then associate this Elastic IP address with the instance.Verify that a firewall isn't blocking accessIf the instance meets the preceding conditions and internet connectivity issues persist, then you might have a local firewall running in the operating system. It's a best practice to use security groups instead of having a local firewall in the operating system. Be sure that disabling the local firewall doesn't impact your workload.# For Uncomplicated Firewallsudo ufw disable# For firewalldsudo systemctl disable firewalld --nowIf you must use a firewall, then the internet connectivity issues are usually related to the OUTPUT chain. You can allow outgoing traffic by running the following commands:sudo iptables -P OUTPUT ACCEPTsudo iptables -I OUTPUT 1 -j ACCEPTWindows Server:For Windows Server default firewalls, run the following command:netsh advfirewall firewall show rule name=allIf the preceding command indicates blocked traffic, then remove the old rule or add a new rule allowing traffic for that specific port. For more information, see the Microsoft documentation for Understanding Windows firewall with advanced security rules.Related informationConnect to the internet using an internet gatewayControl traffic to resources using security groupsWhy can't my Amazon EC2 instance in a private subnet connect to the internet using a NAT gateway?Follow"


Question: How can I activate a BAA agreement for my organization using AWS Artifact?

I need to activate or manage a Business Associate Addendum (BAA) agreement for AWS Organizations with an AWS account for an organization.

Answer: "I need to activate or manage a Business Associate Addendum (BAA) agreement for AWS Organizations with an AWS account for an organization.Short descriptionAWS BAA agreements are required for some organizations that are subject to the Health Insurance Portability and Accountability Act (HIPAA). HIPAA compliance safeguards protected health information (PHI). You can use AWS Artifact to manage agreements for your AWS account or for all accounts in your organization if you use AWS Organizations. For more information, see Managing agreements in AWS Artifact.ResolutionFollow these instructions to download and accept the AWS BAA agreement with a single AWS account or multiple accounts in an organization for AWS Organizations.Managing an agreement for a single account in AWS ArtifactManaging an agreement for multiple accounts in AWS ArtifactIn the AWS Artifact console, the Agreement state is now Active.Related informationIntroducing the Self-Service Business Associate AddendumHow to use AWS Artifact to accept an agreement for your accountHIPAA eligible services referenceAWS Artifact FAQsFollow"