Question: How do I resolve "ResourceInitializationError: failed to validate logger args" error in Amazon ECS?

"When I run a task in Amazon Elastic Container Service (Amazon ECS), I receive a "ResourceInitializationError: failed to validate logger args" error."

Answer: "When I run a task in Amazon Elastic Container Service (Amazon ECS), I receive a "ResourceInitializationError: failed to validate logger args" error.Short descriptionWhen an Amazon ECS task can't find the Amazon CloudWatch log group that's defined in the task definitionAmazon, Amazon ECS returns a ResourceInitialization error. You receive the following error message: "ResourceInitializationError: failed to validate logger args: create stream has been retried 1 times: failed to create Cloudwatch log stream: ResourceNotFoundException: The specified log group does not exist. : exit status 1"To resolve the error, create a new log group for the task.ResolutionTo resolve the ResourceInitialization error, review the following solutions to create a new log group for the task.If you don't know which log group is defined in the task definition and returning an error, then run the following command:aws ecs describe-task-definition --task-definition nginx-fargate:3 | jq -r .taskDefinition.containerDefinitions[].logConfigurationThe output describes the log group that you must recreate in CloudWatch.Create a CloudWatch log group in the console1.    Open the CloudWatch console.2.    From the navigation bar, choose the Region where Amazon ECS cluster is located.3.    In the left navigation pane, choose Logs and then select Log groups.4.    In the Log groups window, choose Create log group.Create a CloudWatch log group using AWS CLICreate a CloudWatch log group with the create-log-group AWS Command Line Interface (AWS CLI) command. The following example command creates a log group named mylogs:Note: If you receive errors when running AWS CLI commands, then make sure that you’re using the most recent version of the AWS CLI.aws logs create-log-group --log-group-name mylogsUse the auto-configuration feature in the Amazon ECS consoleThe auto-configure option creates a log group on your behalf using the task definition family name with ecs as the prefix. The following example specifies a Log Configuration in your Task Definition:{  "containerDefinitions": [    {      "logConfiguration": {        "logDriver": "awslogs",        "options": {          "awslogs-create-group": "true",          "awslogs-group": "awslogs-wordpress",          "awslogs-region": "us-west-2",          "awslogs-stream-prefix": "awslogs-example"        }      }    }  ]}You can also create a custom log group with the following steps:1.    Specify log configuration options.   Add the key awslogs-create-group with a value of true. This creates the log group on your behalf.The following example specifies a Log Configuration in your Task Definition with options set:{  "containerDefinitions": [    {      "logConfiguration": {        "logDriver": "awslogs",        "options": {          "awslogs-group": "example_container",          "awslogs-region": "eu-west-1",          "awslogs-create-group": "true",          "awslogs-stream-prefix": "example"        }      }    }  ]}Note: Managed AWS Identity and Access Management (IAM) policy AmazonECSTaskExecutionRolePolicy doesn't include logs:CreateLogGroup permissions. To use the awslogs-create-group option, add logs:CreateLogGroup as an inline IAM policy.Follow"


Question: How do I set up table mappings in AWS DMS?

How do I set up table mappings in AWS Database Migration Service (AWS DMS)?

Answer: "How do I set up table mappings in AWS Database Migration Service (AWS DMS)?ResolutionUse the steps in this article to set up table mapping on your AWS DMS task using the AWS DMS console. For more information on working with table mapping and how it can be used, see Using table mapping to specify task settings. You can also use transformations in a table mapping to perform tasks like renaming tables, and removing a table column. You must choose at least one selection rule for your task to work correctly, and to use transformation rules on your task. For more information, see the limitations of using transformation rules.Follow these steps to set up table mappings.Open the AWS DMS console, and then choose Database migration tasks from the navigation pane.Choose Create task.Enter the details for your Task configuration and Task settings.Choose Enable CloudWatch logs.From the Table mappings section, choose Guided UI. You can also choose JSON editor to enter the mappings in JSON format.From the Selection rules section, choose Add new selection rule.Note: To add more than one selection rule, choose Add new selection rule again.Enter your Schema and a Table name. Enter % to select all available schemas or tables.For Action, choose Include or Exclude.Choose Create task.To add table mappings to a task that already exists:Choose Database migration tasks from the navigation pane.Choose your task, choose Actions, and then choose Modify.From the Table mappings section, expand Selection rules, and then choose Add new selection rule.Enter the details of your selection rule, and then choose Save.Related informationCreating a taskTroubleshooting migration tasks in AWS Database Migration ServiceHow can I turn on monitoring for an AWS DMS task?Follow"


Question: How do I connect to my Amazon MSK cluster using the Kafka-Kinesis-Connector?

"When I try to use the Kafka-Kinesis-Connector to connect with Amazon Managed Streaming for Apache Kafka (Amazon MSK), I receive an error message. How do I connect to my Amazon MSK cluster using the Kafka-Kinesis-Connector?"

Answer: "When I try to use the Kafka-Kinesis-Connector to connect with Amazon Managed Streaming for Apache Kafka (Amazon MSK), I receive an error message. How do I connect to my Amazon MSK cluster using the Kafka-Kinesis-Connector?Short descriptionTo connect to your MSK cluster using the Kafka-Kinesis-Connector, your setup must meet the following requirements:An active AWS subscription.A virtual private cloud (VPC) that is visible to both the client machine and MSK cluster. The MSK cluster and client must reside in the same VPC.Connectivity to MSK and Apache Zookeeper servers.Two subnets associated to your VPC.Topics created in MSK to send and receive messages from the server.ResolutionBuilding your project file1.    Clone the kafka-kinesis-connector project to download the Kafka-Kinesis-Connector.2.    Use the mvn package command to build the amazon-kinesis-kafka-connector-X.X.X.jar file in the target directory:[ec2-user@ip-10-0-0-71 kinesis-kafka-connector]$ mvn package........[INFO] Replacing /home/ec2-user/kafka-kinesis-connector/kafka-kinesis-connector/target/amazon-kinesis-kafka-connector-0.0.9-SNAPSHOT.jar with /home/ec2-user/kafka-kinesis-connector/kafka-kinesis-connector/target/amazon-kinesis-kafka-connector-0.0.9-SNAPSHOT-shaded.jar[INFO] ------------------------------------------------------------------------[INFO] BUILD SUCCESS[INFO] ------------------------------------------------------------------------[INFO] Total time: 28.822 s[INFO] Finished at: 2020-02-19T13:01:31Z[INFO] Final Memory: 26M/66M[INFO] ------------------------------------------------------------------------The Kafka-Kinesis-Connector looks for credentials in the following order: environment variables, java system properties, and the credentials profile file.3.    Update your configuration to the DefaultAWSCredentailsProviderChain setting:[ec2-user@ip-10-0-0-71 target]$ aws configureThis command makes sure that the access key attached to the AWS Identity and Access Management (IAM) user has the minimum required permissions. The aws configure command also makes sure that there is a policy available to access Amazon Kinesis Data Streams or Amazon Kinesis Data Firehose. For more information about setting AWS credentials, see Working with AWS credentials.Note: If you are using a Java Development Kit (JDK), you can also use the EnvironmentVariableCredentialsProvider class to provide credentials.4.    If you are using Kinesis Data Streams, then update your policy to the following:{     "Version": "2012-10-17",     "Statement": [{          "Sid": "Stmt123",          "Effect": "Allow",          "Action": [               "kinesis:DescribeStream",               "kinesis:PutRecord",               "kinesis:PutRecords",               "kinesis:GetShardIterator",               "kinesis:GetRecords",               "kinesis:ListShards",               "kinesis:DescribeStreamSummary",               "kinesis:RegisterStreamConsumer"          ],          "Resource": [               "arn:aws:kinesis:us-west-2:123xxxxxxxxx:stream/StreamName"          ]     }]}If you are using Kinesis Data Firehose, then update your policy to look like the following example:{     "Version": "2012-10-17",     "Statement": [{          "Effect": "Allow",          "Action": [               "firehose:DeleteDeliveryStream",               "firehose:PutRecord",               "firehose:PutRecordBatch",               "firehose:UpdateDestination"          ],          "Resource": [               "arn:aws:firehose:us-west-2:123xxxxxxxxx:deliverystream/DeliveryStreamName"          ]     }]}For more information about the Kinesis Data Firehose delivery stream settings, see Configuration and credential file settings.Configuring the connectorNote: You can configure the Kafka-Kinesis-Connector to publish messages from MSK. Messages can be published to the following destinations: Amazon Simple Storage Service (Amazon S3), Amazon Redshift, or Amazon OpenSearch Service.1.    If you are setting up Kinesis Data Streams, you can configure the connector with the following values:name=YOUR_CONNECTER_NAMEconnector.class=com.amazon.kinesis.kafka.AmazonKinesisSinkConnectortasks.max=1topics=YOUR_TOPIC_NAMEregion=us-east-1streamName=YOUR_STREAM_NAMEusePartitionAsHashKey=falseflushSync=true# Use new Kinesis Producer for each PartitionsingleKinesisProducerPerPartition=true# Whether to block new records from putting onto Kinesis Producer if# threshold for outstanding records have reachedpauseConsumption=trueoutstandingRecordsThreshold=500000# If outstanding records on producers are beyond threshold sleep for following period (in ms)sleepPeriod=1000# If outstanding records on producers are not cleared sleep for following cycle before killing the taskssleepCycles=10# Kinesis Producer Configuration - https://github.com/awslabs/amazon-kinesis-producer/blob/main/java/amazon-kinesis-producer-sample/default_config.properties# All kinesis producer configuration have not been exposedmaxBufferedTime=1500maxConnections=1rateLimit=100ttl=60000metricsLevel=detailedmetricsGranuality=shardmetricsNameSpace=KafkaKinesisStreamsConnectoraggregation=true-or-If you are setting up a different type of stream, configure the Kinesis Data Firehose delivery stream properties like this:name=YOUR_CONNECTER_NAMEconnector.class=com.amazon.kinesis.kafka.FirehoseSinkConnectortasks.max=1topics=YOUR_TOPIC_NAMEregion=us-east-1batch=truebatchSize=500batchSizeInBytes=3670016deliveryStream=YOUR_DELIVERY_STREAM_NAME2.    Configure the worker properties for either standalone or distributed mode:bootstrap.servers=localhost:9092key.converter=org.apache.kafka.connect.storage.StringConvertervalue.converter=org.apache.kafka.connect.storage.StringConverter#internal.value.converter=org.apache.kafka.connect.storage.StringConverter#internal.key.converter=org.apache.kafka.connect.storage.StringConverterinternal.value.converter=org.apache.kafka.connect.json.JsonConverterinternal.key.converter=org.apache.kafka.connect.json.JsonConverterkey.converter.schemas.enable=truevalue.converter.schemas.enable=trueinternal.key.converter.schemas.enable=trueinternal.value.converter.schemas.enable=trueoffset.storage.file.filename=offset.logFor more information about Kafka-Kinesis-Connector's standalone or distributed mode, see Kafka Connect on the Apache website.3.    Copy the amazon-kinesis-kafka-connector-0.0.X.jar file to your directory and export classpath.Note: You can also add the amazon-kinesis-kafka-connector-0.0.X.jar file to the JAVA_HOME/lib/ext directory.4.    Run the kafka-kinesis-connector by using the following command syntax:[ec2-user@ip-10-0-0-71 kafka_2.12-2.2.1]$ ./bin/connect-standalone.sh /home/ec2-user/kafka-kinesis-connector/kafka-kinesis-connector/worker.properties /home/ec2-user/kafka-kinesis-connector/kafka-kinesis-connector/kinesis-kafka-streams-connecter.propertiesRelated informationCreating an Amazon MSK clusterFollow"


Question: How do I troubleshoot issues with real-time metrics in Amazon Connect?

"In Amazon Connect, I want to troubleshoot common issues with real-time metrics."

Answer: "In Amazon Connect, I want to troubleshoot common issues with real-time metrics.ResolutionBefore troubleshooting issues with real-time metrics, be sure you have the permissions required to view real-time metric reports.Real-time metrics refreshThe numerical data for real-time metrics updates every 15 seconds for active pages. The real-time metrics reflect Agent status changes in the dashboard between Active, Availability, Missed, and Occupancy, with a small delay.Note: The Amazon Connect near real-time metrics refresh about a minute after a contact ends.Agent statusOnly agents who are logged in are seen in the real-time metrics dashboard. Agents that are logged out won't be seen in the real-time metrics dashboard.Viewing all queuesOnly active queues are seen on the real-time metrics report page. If you want to see multiple queues, then change the time range displayed.Note: The real-time metrics reports pull only the first 100 queues for active data. Active queues greater than 100 won't be seen.Barge live conversationsError message: Something went wrong-or-Failed to Monitor Agent DataTo troubleshoot issues with the barge feature, be sure you have turned on the Enhanced Monitoring capability. Also, be sure you have assigned the correct security profile permissions to barge a live conversation.Note: The status of the agent must be Available to barge a call.To barge a call, you must also set recording and analytics behavior in the contact flow. If the Set recording and analytics behavior flow block is missing, then you see a 400 Bad Request HTTP error.If you still can't barge a live conversation, then do the following:Create a HAR file to capture the events when using the barge feature.Create an AWS Support case.Attach the HAR file to the support case.APIs for real-time metricsThe GetCurrentMetricData API retrieves all the values of the real-time metrics dashboard. The dashboard is generated based on the values retrieved from the GetCurrentMetricData API.Contacts removed from the queue percentageReal-time metrics include SL X for contacts removed from the queue between zero and X (service level time in seconds). Both zero and X are considered in the calculations. This means that if the service level is 30, then the percentage of contacts removed from the queue between zero and 30 includes 30.For example, if you preset your X to 30, then the percentage of contacts removed from the queue calculation is between zero and 30. In this example, when calculating the service level of 30, the SL X metric includes both zero and 30 in the calculation.Follow"


Question: How do I add a second Elastic IP address to an elastic network interface attached to my EC2 instance running CentOS 6 or RHEL 6?

How do I add a second Elastic IP address to an elastic network interface attached to my Amazon Elastic Compute Cloud (Amazon EC2) instance running CentOS 6 or RHEL 6 and have it persist during bootup?

Answer: "How do I add a second Elastic IP address to an elastic network interface attached to my Amazon Elastic Compute Cloud (Amazon EC2) instance running CentOS 6 or RHEL 6 and have it persist during bootup?Short descriptionWhen you add a second Elastic IP address to an elastic network interface, that Elastic IP address is lost when you reboot the interface. To make the second Elastic IP address persist during the reboot, you must create a second interface configuration file (ICF).ICFs control the software interfaces for individual network devices. The system uses these files as it boots to determine what interfaces to bring up and how to configure them.The default ICF is /etc/sysconfig/network-scripts/ifcfg-eth0. When two Elastic IP addresses exist on a single interface, the second Elastic IP address becomes ":1"—that is, /etc/sysconfig/network-scripts/ifcfg-eth0:1.ResolutionCreate a second interface configuration file1.    Attach two Elastic IP addresses to the elastic network interface from the Amazon EC2 console. For more information, see Multiple IP addresses.2.    Use the touch command to create the ifcfg-eth0:1 file for the second Elastic IP address in the /etc/sysconfig/network-scripts/ directory:$ sudo touch /etc/sysconfig/network-scripts/ifcfg-eth0:13.    Add the following parameters to the ifcfg-eth0:1 file:DEVICE=eth0:1BOOTPROTO=staticNETMASK=255.255.255.0ONBOOT=yesTYPE=EthernetIPADDR=172.31.34.195Note: IPADDR uses the private IP address associated with the second Elastic IP address you associated with the interface. After you select your instance, you can find the private IP address in the Amazon EC2 console under Secondary private IPs.Change the context of the second ICF to match the default ICF1.    To view the security context of the ifcfg-eth0:1 file, use the –Z option with the ls command:$ ls -Z ifcfg-eth*2.    Change the user to system_u using the –u option with the chcon command:$ sudo chcon -u system_u ifcfg-eth0:13.    Change the type to net_conf_t using the –t option with the chcon command:$ sudo chcon -t net_conf_t ifcfg-eth0:14.    Compare the two files by running the following command:$ ls -Z ifcfg-eth0*-rw-r--r--. root root system_u:object_r:net_conf_t:s0  ifcfg-eth0-rw-r--r--. root root system_u:object_r:net_conf_t:s0  ifcfg-eth0:1Bring up the interface1.    Bring up the second interface by running the ifup command:$ sudo ifup eth0:12.    If there are issues with the second ICF, run the ethtool command to verify detection of the second ICF:$ ethtool eth0:1The output appears similar to the following:Settings for eth0:1:Link detected: yesIf the output isn't as expected, run the ifup command and verify that the second interface is present. Then, review the ICF file to be sure that it is correct, and reload it.Reboot the instanceReboot your instance by running the reboot command.Related informationElastic IP addressesElastic network interfacesFollow"


Question: Why can't I connect to my Amazon EC2 Linux instance using SSH?

I can't connect to my Amazon Elastic Compute Cloud (Amazon EC2) Linux instance and want to troubleshoot the issue.

Answer: "I can't connect to my Amazon Elastic Compute Cloud (Amazon EC2) Linux instance and want to troubleshoot the issue.Short descriptionTo troubleshoot the issue, log in to the EC2 instance over SSH with verbose messaging on. Use the output messages from the SSH client to determine the type of issue. Then, follow the troubleshooting steps in this article to resolve the issue.ResolutionLog in to your instance to identify the issue1.    Log in to the EC2 instance over SSH with verbose messaging on:user@localhost:~$ ssh -v -i my_key.pem ec2-user@11.22.33.44This example uses my_key.pem for the private key file, and a user name of ec2-user@11.22.33.44. Substitute your key file and your user name for the example's key file and user name. For more information, see Connect to your Linux instance using SSH.2.    Use the output messages from the SSH client to determine the type of issue you are experiencing.Use the EC2 Serial Console for Linux to troubleshoot Nitro-based instance typesIf you turned on EC2 Serial Console for Linux, you can use it to troubleshoot supported Nitro-based instance types. You can access the serial console using the serial console or the AWS Command Line Interface (AWS CLI). You don't need a working connection to connect to your instance when you use the EC2 Serial console.Before you use the serial console to troubleshoot:Grant access to the serial console at the account levelCreate AWS Identity and Access Management (IAM) policies granting access to your IAM usersCheck that your instance includes at least on password-based userIf connecting with EC2 Instance Connect using the AWS CLI, make sure that you’re using the most recent version of the AWS CLI.Troubleshoot common errorsError: "Connection timed out" or "Connection refused": To resolve this error, see I'm receiving "Connection refused" or "Connection timed out" errors when trying to connect to my EC2 instance with SSH. How do I resolve this?"connection timed out" errors on a virtual private cloud (VPC): To resolve this error, see How do I troubleshoot Amazon EC2 instance connection timeout errors from the internet?Error: "Permission denied" or "Authentication failed": To resolve this error, see I'm receiving "Permission denied (publickey)" or "Authentication failed, permission denied" errors when trying to access my EC2 instance. How do I resolve this?Error: "Server refused our key": To resolve this error, see Why am I getting a "Server refused our key" error when I try to connect to my EC2 instance using SSH?Error: "imported-openssh-key" or "Putty Fatal Error": To resolve this error, see Why am I receiving "imported-openssh-key" or "Putty Fatal Error" errors when connecting to my Amazon Elastic Compute Cloud (Amazon EC2) Linux instance?Error: "Enter passphrase for key 'my_key.pem'":This error occurs if you created a password for your key file, but haven't manually entered the password. To resolve this error, enter the password or use ssh-agent to load the key automatically.Automatically troubleshoot SSH errorsThere are a number of reasons why you might get an SSH error, like Resource temporarily unavailable. Run the AWSSupport-TroubleshootSSH automation document to automatically find and resolve errors like this.Related informationHow do I troubleshoot issues connecting to my EC2 instance using EC2 Instance Connect?How do I troubleshoot SSH or RDP connectivity to my EC2 instances launched in a Wavelength Zone?Troubleshoot connecting to your instanceFollow"


Question: How can I receive Amazon SNS notifications when my AWS Glue job changes states?

"I want to get a notification when an AWS Glue extract, transform, and load (ETL) job succeeds, fails, times out, or stops."

Answer: "I want to get a notification when an AWS Glue extract, transform, and load (ETL) job succeeds, fails, times out, or stops.Short descriptionCreate and subscribe to an Amazon Simple Notification Service (Amazon SNS) topic. Then, create an Amazon EventBridge event rule for each state change that you want to monitor.Note: For this issue, it's a best practice to use Amazon EventBridge instead of Amazon CloudWatch.ResolutionCreate and subscribe to an Amazon SNS topic1.    Open the Amazon SNS console.2.    Select Topics, and then select Create topic.3.    Enter a Topic name. The Display name field is optional.4.    Select Create topic.5.    Select Subscriptions from the navigation pane. Then, choose Create subscription.6.    Under Details, complete the following fields:        For Topic ARN, choose the ARN of the topic that you created.        For Protocol, choose Email.        For Endpoint, enter the email address that you want the notifications to be sent to.7.    Select Create subscription.8.    Check your email account, and wait to receive a subscription confirmation email message. When you receive it, select the Confirm subscription link.Create an EventBridge event rule1.    Open the EventBridge console.2.    In the navigation pane, select Rules, and then select Create rule.3.    Enter a name for your rule. Leave the other fields as their default selections, and then select Next.4.    Scroll down to the Creation method section, and choose Custom pattern (JSON editor).5.    In the Event pattern box, enter code similar to the following. Replace job_name with the name of your AWS Glue ETL job. For state, enter the state changed that you want to be notified about (SUCCEEDED, FAILED, TIMEOUT, or STOPPED). Create separate event rules for each state change that you want to monitor:{  "detail-type": "Glue Job State Change",  "source": "aws.glue",  "detail": {    "jobName": "MyJob",    "state": "SUCCEEDED"  }}6.    Select Next. This brings you to the Select target(s) page.7.    For Target types, choose AWS service. Then, choose SNS topic from the dropdown list.8.    In the Topic dropdown list, choose the name of the SNS topic that you created earlier.9.    Select Next. This brings you to the Configure tags - optional page. Select Next, and then select Create rule.To test the event rule and SNS topic, run an AWS Glue job. Verify that you receive an email notification when the job changes to the state that you specified in the event rule.Related informationHow can I use an AWS Lambda function to receive SNS alerts when an AWS Glue job fails a retry?How can I automatically start an AWS Glue job when a crawler run completes?Automating AWS Glue with CloudWatch EventsAWS Glue EventsFollow"


Question: How do I use my CloudFront distribution to restrict access to an Amazon S3 bucket?

I want to restrict access to my Amazon Simple Storage Service (Amazon S3) bucket so that users access objects only through my Amazon CloudFront distribution.

Answer: "I want to restrict access to my Amazon Simple Storage Service (Amazon S3) bucket so that users access objects only through my Amazon CloudFront distribution.ResolutionImportant: Before you begin, be sure that the Amazon S3 origin of your CloudFront distribution is configured as a REST API endpoint. For example, AWSDOC-EXAMPLE-BUCKET.s3.amazonaws.com. This resolution doesn't apply to S3 origins that are configured as a website endpoint. For example, AWSDOC-EXAMPLE-BUCKET.s3-website-us-east-1.amazonaws.com. For more information, see How do I use CloudFront to serve a static website hosted on Amazon S3?Option 1 (Best practice): Create a CloudFront origin access control (OAC)Open the CloudFront console.From the list of distributions, choose the distribution that serves content from the S3 bucket that you want to restrict access to.Choose the Origins tab.Select the S3 origin, and then choose Edit.For Origin Access, select Origin access control settings (recommended).For Origin access control, select an existing OAC, or choose the Create Control setting.In the dialogue box, name your control setting. It's a best practice to keep the default setting as Sign requests (recommended). Then, choose Create.For S3 bucket Access, apply the bucket policy on the S3 bucket. Select Copy policy, and then select Save.Select Go to S3 bucket permissions to take you to the S3 bucket console.Select Save Changes.In the Amazon S3 console, from your list of buckets, choose the bucket that's the origin of the CloudFront distribution.Choose the Permissions tab.Under Bucket Policy, confirm that you see a statement similar to the following:{    "Version": "2012-10-17",    "Statement": {        "Sid": "AllowCloudFrontServicePrincipalReadOnly",        "Effect": "Allow",        "Principal": {            "Service": "cloudfront.amazonaws.com"        },        "Action": "s3:GetObject",        "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",        "Condition": {            "StringEquals": {                "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/EDFDVBD6EXAMPLE"            }        }    }}You must add the preceding statement to allow CloudFront OAC to read objects from your bucket.Note: After you restrict access to your bucket using the CloudFront OAC, you have the option to add another layer of security by integrating AWS WAF.Option 2: Create a legacy CloudFront origin access identity (OAI)Open the CloudFront console.From the list of distributions, choose the distribution that serves content from the S3 bucket that you want to restrict access to.Choose the Origins tab.Select the S3 origin, and then choose Edit.For Origin Access, select Legacy access identities.In the Origin access identity dropdown list, select the origin access identity name, or choose Create new OAI.In the dialog box, name your new origin access identity, and choose Create.For Bucket policy, select Yes, update the bucket policy.Choose Save Changes.In the  Amazon S3 console,from your list of buckets, Choose the bucket that's the origin of the CloudFront distribution.Choose the Permissions tab.Under Bucket Policy, confirm that you see a statement similar to the following:{{"Sid": "1","Effect": "Allow","Principal": {"AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity EAF5XXXXXXXXX"},"Action": "s3:GetObject","Resource": "arn:aws:s3:::AWSDOC-EXAMPLE-BUCKET/*"}Note: Review your bucket policy for any statements with "Effect": "Deny" that prevent access to the bucket from the CloudFront OAI. Modify those statements so that the CloudFront OAI can access objects in the bucket.Also, review your bucket policy for any statements with "Effect": "Allow" that allow access to the bucket from any source that's not the CloudFront OAI. Modify those statements as required by your use case.Related informationCreating a distributionIdentity and access management in Amazon S3Follow"


Question: How do I resolve cluster creation errors in Amazon EKS?

I get service errors when I provision an Amazon Elastic Kubernetes Service (Amazon EKS) cluster using AWS CloudFormation or eksctl.

Answer: "I get service errors when I provision an Amazon Elastic Kubernetes Service (Amazon EKS) cluster using AWS CloudFormation or eksctl.Short descriptionConsider the following troubleshooting options:You receive an error message stating that your targeted Availability Zone doesn't have sufficient capacity to support the cluster. Complete the steps in the Recreate the cluster in a different Availability Zone section.You receive an error message stating that resource creation failed. Complete the steps in the Confirm that you have the correct IAM permissions to create a cluster section, or the Monitor your Amazon VPC resources section.You receive an error message stating that the creation timed out when waiting for worker nodes. Complete the steps in the Confirm that your worker nodes can reach the control plane API endpoint section.ResolutionRecreate the cluster in a different Availability ZoneIf you launch control plane instances in an Availability Zone with limited capacity, then you can receive an error that's similar to the following:Cannot create cluster 'sample-cluster' because us-east-1d, the targeted availability zone, does not currently have sufficient capacity to support the cluster. Retry and choose from these availability zones: us-east-1a, us-east-1b, us-east-1cTo resolve the preceding error, create the cluster again using the recommended Availability Zones from the error message.If you're provisioning the cluster using CloudFormation, then in the Subnets parameter add subnet values that match the Availability Zones.-or-If you're using eksctl, then use the --zones flag to add the values for the different Availability Zones. For example:$ eksctl create cluster 'sample-cluster' --zones us-east-1a,us-east-1b,us-east-1cNote: Replace sample-cluster with your cluster name. Replace us-east-1a, us-east-1b, and us-east-1c with your Availability Zones.Confirm that you have the correct IAM permissions to create a clusterWhen you create a cluster, verify that you have the correct AWS Identity and Access Management (IAM) permissions. This includes correct policies for the Amazon EKS service IAM role.You can use eksctl to create the prerequisite resources for your cluster, such as the IAM roles and security groups. The required minimum permissions depend on the eksctl configuration that you're launching. For more information, see troubleshooting solutions from the eksctl GitHub community.If your cluster has issues with IAM permissions, then you can receive an error in eksctl that's similar to the following:API: iam:CreateRole User: arn:aws:iam::your-account-id:user/your-user-name is not authorized to perform: iam:CreateRole on resource: arn:aws:iam::your-account-id:role/eksctl-newtest22-cluster-ServiceRole-10NXBYLSN4ULPTo resolve the preceding error, review the minimum IAM policies for running eksctl use cases on the eksctl website. Also, see Identity and Access Management for Amazon EKS, and How can I troubleshoot access denied or unauthorized operation errors with an IAM policy?Monitor your Amazon VPC resourcesWhen you create a cluster, eksctl creates a new Amazon Virtual Private Cloud (Amazon VPC) by default. If you don't want eksctl to create a new Amazon VPC, then you must specify your custom Amazon VPC and subnets in the configuration file.If your cluster has issues with your Amazon VPC limits, then you can receive the following error message:The maximum number of VPCs has been reached. (Service: AmazonEC2; Status Code: 400; Error Code: VpcLimitExceeded; Request ID: a12b34cd-567e-890-123f-ghi4j56k7lmn)To resolve the preceding error, monitor your resources. For example, check the number of Amazon VPCs in your AWS Region or the internet gateways per Region where you create the cluster. For more information, see Amazon VPC quotas.For issues related to resource constraints on the number of Amazon VPC resources in your Region, consider one of the following options:(Option 1) Use an existing Amazon VPC to overcome resource constraintsCreate a configuration file that specifies the Amazon VPC and subnets where you want to provision your cluster's worker nodes:$ eksctl create cluster sample-cluster -f cluster.yaml-or-(Option 2) Request a service quota increase to overcome resource constraintsRequest a service quota increase for the resources in the CloudFormation stack events of the cluster that eksctl provisioned.Confirm that your worker nodes can reach the control plane API endpointWhen eksctl deploys your cluster, it waits for the launched worker nodes to join the cluster and reach Ready status. If your worker nodes don't reach the control plane or have an invalid IAM role, then you can receive the following error:timed out (after 25m0s) waiting for at least 4 nodes to join the cluster and become ready in "eksfbots-ng1"To resolve the preceding error, get your worker nodes to join the cluster, and confirm that your worker nodes are in Ready status.Follow"


Question: How do I create a Python 3 virtual environment with the Boto 3 library on Amazon Linux 2?

How do I create an isolated Python 3 virtual environment with the Boto 3 library on an Amazon Elastic Compute Cloud (Amazon EC2) instance or on-premise solution that's running Amazon Linux 2?

Answer: "How do I create an isolated Python 3 virtual environment with the Boto 3 library on an Amazon Elastic Compute Cloud (Amazon EC2) instance or on-premise solution that's running Amazon Linux 2?Short descriptionTo create an isolated Python environment for Amazon Linux 2, you must:1.    Install Python 3 for Amazon Linux 2.2.    Install a virtual environment under the ec2-user home directory.3.    Activate the environment, and then install Boto 3.ResolutionInstall Python 3 for Amazon Linux 21.    Connect to your EC2 Linux instance using SSH. For more information, see Connecting to your Linux instance using SSH.2.    Perform a yum check-update to refresh the package index. The check-update also looks for available updates. Updating other packages shouldn't be required to create the Python 3 environment.3.    Run list installed to determine if Python 3 is already installed on the host.[ec2-user ~]$ yum list installed | grep -i python3Python 3 not installed output example:[ec2-user ~]$ yum list installed | grep -i python3[ec2-user ~]$[ec2-user ~]$ python3-bash: python3: command not foundPython 3 already installed output example:[ec2-user ~]$ yum list installed | grep -i python3python3.x86_64                        3.7.4-1.amzn2.0.4              @amzn2-corepython3-libs.x86_64                   3.7.4-1.amzn2.0.4              @amzn2-corepython3-pip.noarch                    9.0.3-1.amzn2.0.1              @amzn2-corepython3-setuptools.noarch             38.4.0-3.amzn2.0.6             @amzn2-core[ec2-user ~]$ whereis python3python3: //usr/bin/python3 /usr/bin/python3.7 /usr/bin/python3.7m /usr/lib/python3.7 /usr/lib64/python3.7 /usr/include/python3.7m /usr/share/man/man1/python3.1.gz4.    If Python 3 isn't already installed, then install the package using the yum package manager.[ec2-user ~]$ sudo yum install python3 -yCreate a virtual environment under the ec2-user home directoryThe following command creates the app directory with the virtual environment inside of it. You can change my_app to another name. If you change my_app, make sure that you reference the new name in the remaining resolution steps.[ec2-user ~]$ python3 -m venv my_app/envActivate the virtual environment and install Boto 31.    Attach an AWS Identity and Access Management (IAM) role to your EC2 instance with the proper permissions policies so that Boto 3 can interact with the AWS APIs. For other authentication methods, see the Boto 3 documentation.2.    Activate the environment by sourcing the activate file in the bin directory under your project directory.[ec2-user ~]$ source ~/my_app/env/bin/activate(env) [ec2-user ~]$3.    Make sure that you have the latest pip module installed within your environment.(env) [ec2-user ~]$ pip install pip --upgrade4.    Use the pip command to install the Boto 3 library within our virtual environment.(env) [ec2-user ~]$ pip install boto35.    Run Python using the python executable.(env) [ec2-user ~]$ pythonPython 3.7.4 (default, Dec 13 2019, 01:02:18)[GCC 7.3.1 20180712 (Red Hat 7.3.1-6)] on linuxType "help", "copyright", "credits" or "license" for more information.>>>6.    Import the Boto 3 library, and then validate that it works. This step requires that you have the permissions policies configured from step 1. The following example output lists all the Amazon Simple Storage Service (Amazon S3) buckets within the account.>>> import boto3           # no error>>> s3 = boto3.resource('s3')>>> for bucket in s3.buckets.all():print(bucket.name)>>> exit()7.    Use the deactivate command to exit the virtual environment.(env) [ec2-user ~]$ deactivate[ec2-user ~]$8.    To activate the virtual environment automatically when you log in, add it to the ~/.bashrc file.[ec2-user ~]$ echo "source ${HOME}/my_app/env/bin/activate" >> ${HOME}/.bashrc9.    Source the ~/.bashrc file in your home directory to reload your environment's bash environment. Reloading automatically activates your virtual environment. The prompt reflects the change (env). This change also applies to any future SSH sessions.[ec2-user ~]$ source ~/.bashrc(env) [ec2-user ~]$Related informationUpdating instance softwareLaunching an instance using the Launch Instance WizardVirtualenv introductionFollow"


Question: How can AWS WAF help prevent brute force login attacks?

How can I use AWS WAF to help prevent brute force attacks?

Answer: "How can I use AWS WAF to help prevent brute force attacks?Short descriptionA brute force attack is a tactic for gaining unauthorized access to accounts, systems, and networks using trial and error to guess login credentials and encryption keys. This attack is called brute force because a hacker uses excessive forceful attempts to gain access to your accounts.The following AWS WAF features help prevent brute force login attacks:Rate-based rule statementAWS WAF CAPTCHAATP managed rule groupAWS WAF Automation on AWSResolutionRate-based rulesA rate-based rule tracks requests based on the originating IP addresses. The rule invokes if the rate of request exceeds the defined threshold per five-minute interval.Create a rate-based rule to block requests if the rate of requests is greater than expected. To find the threshold for a rate-based rule, you must turn on AWS WAF logging and analyze the logs get the rate of requests. For information on how to create a rate-based rule, see Creating a rule and adding conditions.You can also create a rate-based rule specific to a URI path. Brute force attacks generally target the login pages to get access to account credentials. Different pages on a website might receive different rates of requests. For example, a home page might receive a higher rate of traffic compared to login pages.To create a rate-based rule specific to a login page, use the following rule configuration:For Inspect Request, choose URI path.For Match type, choose Starts with string.For String to match, choose /login.AWS WAF CAPTCHAAWS WAF CAPTCHA challenges verify if requests hitting your website are from a human or a bot. Using CAPTCHA helps prevent brute force attacks, credential stuffing, web scraping, and spam requests to servers.If webpages are designed to receive requests from humans but are susceptible to brute force attacks, then create a rule with a CAPTCHA action. CAPTCHA action requests allow access to a server when the CAPTCHA challenge is successfully completed.To set up a CAPTCHA action on your login page, use the following rule configuration:For Inspect choose URI path.For Match Type choose Starts with string.For String to match choose /login.For Action choose CAPTCHA.For Immunity time choose Time in seconds.If a CAPTCHA action is configured, users accessing your login page must complete the CAPTCHA before they can enter their login information. This protection helps prevent brute force attacks from bots.Note: To help prevent brute force attacks from a human, set a low immunity time. A low immunity time slows the attack as the attacker must complete the CAPTCHA for each request. For more information, see Configuring the CAPTCHA immunity time.For more information on AWS WAF CAPTCHA, see AWS WAF CAPTCHA.ATP Managed Rule GroupThe AWS WAF account takeover prevention (ATP) managed rule group inspects malicious requests that attempt to take over your account. For example, brute force login attacks that use trial and error to guess credentials and gain unauthorized access to your account.The ATP rule group is an AWS managed rule group that contains predefined rules that provide visibility and control over requests performing anomalous login attempts.Use the following subset of rules in the ATP rule group to help block brute force attacks:VolumetricIpHighInspects for high volumes of requests sent from individual IP addresses.AttributePasswordTraversalInspects for attempts that use password traversal.AttributeLongSessionInspects for attempts that use long lasting sessions.AttributeUsernameTraversalInspects for attempts that use username traversal.VolumetricSessionInspects for high volumes of requests sent from individual sessions.MissingCredentialInspects for missing credentials.For more information on how to set up an ATP rule-group, see AWS WAF Fraud Control account takeover prevention (ATP).AWS WAF Automation on AWSAWS WAF Security Automation is an AWS CloudFormation template used to deploy a web ACL with a set of rules. You can activate these rules based on your use case. When a hacker attempts to guess the correct credentials as part of brute force attack, they receive an error code for each incorrect login attempt. For example, an error code might be a 401 Unauthorized response.The Scanners and probes rule can block requests sourcing from an IP that is continuously receiving a specific response code. Activating this rule deploys an AWS Lambda function or an Amazon Athena query that automatically parses Amazon CloudFront, or Application Load Balancer (ALB), access logs to check the HTTP response code from your backend server. If the number of requests receiving the error code reaches a defined threshold, then the rule blocks these requests for a custom period of time that you can configure.For more information on this template and how to deploy it, see Automatically deploy a single web access control list that filters web-based attacks with AWS WAF Automation on AWS.Follow"


Question: "How can I monitor the account activity of specific IAM users, roles, and AWS access keys?"

I want to view and monitor the account activity of specific AWS Identity and Access Management (IAM) identities.

Answer: "I want to view and monitor the account activity of specific AWS Identity and Access Management (IAM) identities.Short descriptionTo view and monitor the account activity of specific IAM identities, you can use any of the following AWS services and features:AWS CloudTrail event historyAmazon CloudWatch Logs InsightsAmazon Athena queriesResolutionTo use CloudTrail event historyNote: You can use CloudTrail to search event history for the last 90 days.1.    Open the CloudTrail console.2.    Choose Event history.3.    In Filter, select the dropdown list. Then, choose User name.Note: You can also filter by AWS access key.4.    In the Enter user or role name text box, enter the IAM user's "friendly name" or the assumed role session name.Note: The role session name for a specific session is the value provided as a session name when the role is assumed. Value for "User name" field won't be the role name for calls made using the IAM role.5.    In Time range, enter the desired time range. Then, choose Apply.6.    In Event time, expand the event. Then, choose View event.The userIdentity element contains details about the type of IAM identity that made the request and the credentials provided.Example userIdentity element that includes IAM user credentials used to make an API callNote: Replace Alice with the username that you're searching for. Enter the IAM user's "friendly name" or the assumed role's "role session name." The role session name for a specific session is the value provided as a session name when the role is assumed. For calls made using the IAM role, the value for the userName field isn't the role name."userIdentity": {  "type": "IAMUser",  "principalId": "AIDAJ45Q7YFFAREXAMPLE",  "arn": "arn:aws:iam::123456789012:user/Alice",  "accountId": "123456789012",  "accessKeyId": "AKIAIOSFODNN7EXAMPLE",  "userName": "Alice"}Example userIdentity element that includes temporary security credentials"userIdentity": {    "type": "AssumedRole",    "principalId": "AROAIDPPEZS35WEXAMPLE:AssumedRoleSessionName",    "arn": "arn:aws:sts::123456789012:assumed-role/RoleToBeAssumed/AssumedRoleSessionName",     "accountId": "123456789012",    "accessKeyId": "AKIAIOSFODNN7EXAMPLE",    "sessionContext": {      "attributes": {        "mfaAuthenticated": "false",        "creationDate": "20131102T010628Z"      },      "sessionIssuer": {        "type": "Role",        "principalId": "AROAIDPPEZS35WEXAMPLE",        "arn": "arn:aws:iam::123456789012:role/RoleToBeAssumed",        "accountId": "123456789012",        "userName": "RoleToBeAssumed"      }   }}Note: CloudTrail event history uses the assumed role session name as the username for filtering events.The API call uses temporary security credentials obtained by assuming an IAM role. The element contains additional details about the role assumed to get credentials.Note: If you don't see user activity, then verify that the AWS service is supported and the API event is recorded by CloudTrail. For more information, see AWS service topics for CloudTrail.To use CloudWatch Logs InsightsNote: You can use CloudWatch Logs Insights to search API history beyond the last 90 days. You must have a trail created and configured to log to Amazon CloudWatch Logs. For more information, see Creating a trail.1.    Open the CloudWatch console.2.    Choose Logs.3.    In Log Groups, choose your log group.4.    Choose Search Log Group.5.    In Filter events, enter a query to either search for a user's API calls, or specific API actions. Then, choose the refresh icon.Example query to search logs for a user's API callsNote: Replace Alice with the username that you're searching for. Enter the IAM user's "friendly name" or the assumed role's "role session name." The role session name for a specific session is the value provided as a session name when the role is assumed. For calls made using the IAM role, the value for the userName field isn't the role name.{ $.userIdentity.userName = "Alice" }Example query to search logs for specific API actionsNote: The following example query searches for the DescribeInstances API action.{ ($.eventName = "DescribeInstances") && ($.requestParameters.userName = "Alice"  ) }For more information, see CloudWatch Logs Insights query syntax.To use Athena queriesNote: You can use Athena to query CloudTrail Logs over the last 90 days.1.    Open the Athena console.2.    Choose Query Editor.3.    Enter one of the following example queries based on your use case. Then, choose Run query:Example query to return all CloudTrail events performed by a specific IAM userImportant: Replace athena-table with your Athena table name. Replace Alice with the IAM user that you want to view account activity for.SELECT *FROM athena-tableWHERE useridentity.type = 'IAMUser'AND useridentity.username LIKE 'Alice';Example query to filter all the API activity performed by an IAM roleNote: Replace role-name with your IAM role name.SELECT *FROM athena-tableWHERE useridentity.sessionContext.sessionissuer.arn LIKE '%role-name%'AND useridentity.sessionContext.sessionissuer.type = 'Role';Example query to match the role ARNSELECT *FROM athena-tableWHERE useridentity.sessionContext.sessionissuer.arn = 'arn:aws:iam::account-id123456789:role/role-name'AND useridentity.sessionContext.sessionissuer.type = 'Role';Example query to filter for all activity using the IAM access key IDSELECT eventTime, eventName, userIdentity.principalId,eventSourceFROM athena-tableWHERE useridentity.accesskeyid like 'AKIAIOSFODNN7EXAMPLE'Related informationHow do I use AWS CloudTrail to track API calls to my Amazon EC2 instances?How do I use CloudTrail to see if a security group or resource was changed in my AWS account?Follow"


Question: How do I resolve connection timeouts when I connect to my Service that's hosted in Amazon EKS?

I get connection timeouts when I connect to my Service that's hosted in my Amazon Elastic Kubernetes Service (Amazon EKS) cluster.

Answer: "I get connection timeouts when I connect to my Service that's hosted in my Amazon Elastic Kubernetes Service (Amazon EKS) cluster.Short descriptionTwo of the most common reasons you can't connect to your Service in your Amazon EKS cluster are:The security group or network access control list (network ACL) restrictions are preventing traffic from reaching the pod endpoints.The Service doesn't select the pod endpoints because the labels don't match.To resolve these issues, check the security groups and network ACLs that are associated with your worker node instances and load balancer. Also, verify that your Service has the correct labels selected for your pods.Note: Troubleshooting varies for different service types. The following resolutions are applicable for when you're troubleshooting inaccessible services. To learn more about Kubernetes Service types, see How do I expose the Kubernetes services running on my Amazon EKS cluster?ResolutionCheck your security group and network ACLsCluster IPThe cluster IP service type is used for communication between microservices that run in the same Amazon EKS cluster. Make sure that the security group that's attached to the instance where the destination pod is located has an inbound rule to allow communication from the client pod instance.In most cases, there's a self rule that allows all communication over all ports in the worker node security groups. If you use multiple node groups, each with its own security group, make sure that you allow all communication between the security groups. This lets the microservices that run across the multiple nodes to communicate easily.To learn more, see Amazon EKS security group considerations.Node portThe worker node security group should allow incoming traffic on the portthat was specified in the NodePort Service definition. If it's not specified in the Service definition, then the value of the port parameter is the same as the targetPort parameter. The port is exposed on all nodes in the Amazon EKS cluster.Check the network ACLS that are linked to the worker node subnets. Make sure that your client IP address is on the allow list over the port that the Service uses.If you're accessing the Kubernetes Service over the internet, make sure that your nodes have a Public IP address. To access the Service, you must use the node's Public IP address and port combination.Load balancerMake sure that the load balancer security group allows the listener ports. Also, make sure that the worker node security group allows incoming traffic from the load balancer security group over the port where the application container is running.If the port that's specified in the Service definition is different from the targetPort, then you must allow the incoming traffic over the port in the worker node security group for the load balancer security group. The port and targetPort are usually the same in the Service definition.The network ACLs must allow your client IP address to reach the load balancer at the listener port. If you're accessing the load balancer over the internet, then make sure that you created a public load balancer.Check if your Service selected the pod endpoints correctlyIf your pods aren't registered as backends for the Service, then you can receive a timeout error. This can happen when you access the Service from a browser or when you run the curl podIP:podPort command.Check the labels for the pods and verify that the Service has the appropriate label selectors (from the Kubernetes website).Run the following commands to verify if your Kubernetes Service correctly selected and registered your pods.Command:kubectl get pods -o wideExample output:NAME                    READY   STATUS    RESTARTS   AGE       IP                           NODE                         NOMINATED NODE   READINESS GATESnginx-6799fc88d8-2rtn8   1/1     Running     0       3h4m   172.31.33.214   ip-172-31-33-109.us-west-2.compute.internal       none          noneCommand:kubectl describe svc your_service_name -n your_namespaceNote: Replace your_service_name with your service name and your_namespace with your namespace.Example output:Events:            noneSession Affinity:  noneEndpoints:         172.31.33.214:80....In the preceding example output, 172.31.33.214 is the pod IP address that was obtained from running the kubectl get pods -o wide command. The 172.31.33.214 IP address also serves as the backend to a service that's running in an Amazon EKS cluster.Follow"


Question: Why did GuardDuty send me alert findings for a trusted IP list address?

I followed the instructions to set up a trusted IP address list for Amazon GuardDuty. Why is GuardDuty sending me alert findings for my trusted IP address?

Answer: "I followed the instructions to set up a trusted IP address list for Amazon GuardDuty. Why is GuardDuty sending me alert findings for my trusted IP address?ResolutionUse the following best practices to verify the trusted IP list settings:Be sure that the trusted IP lists uploaded in the same AWS Region as your GuardDuty findings.Verify that the trusted IP lists are activated. For instructions, see To activate or deactivate trusted IP lists and threat lists.If you changed the trusted IP list, you must reactivate it in GuardDuty. For instructions, see To update trusted IP lists and threat lists.Be sure that IP addresses added in the trusted IP list are publicly routable IPv4 addresses. Support for IPv6 addresses isn't available.Adding a domain name, private IP address, or IPv6 address in a trusted IP list doesn't prevent GuardDuty from generating findings.In member accounts, GuardDuty generates findings for malicious IP addresses from the threat lists uploaded in the GuardDuty administrator account, not the trusted IP lists. For more information, see Managing GuardDuty accounts with AWS Organizations.Related informationWorking with trusted IP lists and threat listsHow to use Amazon GuardDuty and AWS Web Application Firewall to automatically block suspicious hostsFollow"


Question: How do I modify the values of an Amazon RDS DB parameter group?

How do I modify the values of an Amazon Relational Database Service (Amazon RDS) DB parameter group? How can I resolve an issue that I experienced when trying to change my Amazon RDS DB instance configuration?

Answer: "How do I modify the values of an Amazon Relational Database Service (Amazon RDS) DB parameter group? How can I resolve an issue that I experienced when trying to change my Amazon RDS DB instance configuration?Short descriptionYou can modify parameter values in a custom DB parameter group. However, you can't change the parameter values in a default DB parameter group. If you're experiencing an issue while modifying the value of a DB parameter group, review the following common issues:If you use commands such as SET, you might receive an error, because these commands can't be used to update RDS DB instance configurations.If you can't update the DB instance configuration, it might be because you can't change the values of a default RDS DB parameter group.If you changed the parameter values but the changes aren't in effect, it might be because not all modifications are applied immediately.If you can't modify DB parameters under any circumstances, it might be because the parameter's property value for Is Modifiable is false.For more information, see Working with DB parameter groups.ResolutionTo change an RDS DB instance configuration, you must change the parameter values of the DB parameter group for your RDS DB instance. To modify an RDS DB instance configuration, follow these steps:Create a DB parameter group.View the parameter values for a DB parameter group to confirm that the Is Modifiable property is true.Modify the parameters in a DB parameter group.After the custom DB parameter group is applied (by using Apply immediately or by using Apply during the maintenance window), the DB parameter group status for that instance changes to pending-reboot in Amazon RDS console. This means that the parameter group is applied, but the parameter changes aren't applied yet. After a manual reboot of the RDS DB instance, the parameter changes are applied and the DB parameter group status for the instance changes from pending-reboot to in-sync.DB instances require a manual reboot in the following circumstances:If you replace the current parameter group with a different parameter group.If you modify and save a static parameter in a custom parameter group.Static parameter change takes effect after you manually reboot the RDS DB instance. For more information, see Modifying parameters in a DB parameter group.A reboot doesn't occur in the following circumstances:If you modify a dynamic parameter in a custom parameter group.For more information, see Amazon RDS DB parameter changes not taking effect.Related informationModifying an Amazon RDS DB instanceManaging an Amazon Aurora DB clusterFollow"


Question: How do I register for AWS Educate?

I’m interested in registering for AWS Educate. Am I eligible?

Answer: "I’m interested in registering for AWS Educate. Am I eligible?ResolutionAWS Educate is open to any individual, regardless of where they are in their education, technical experience, or career journey.AWS Educate provides access to online training resources and labs to learn, practice, and evaluate cloud skills without having to create an Amazon or AWS account.Individual learners can register for AWS Educate for free. To get started, see AWS Educate registration.Related informationAWS Educate frequently asked questionsHow do I get support from the AWS Educate program?Follow"


Question: How do I resolve the error that I receive in CloudFormation when I try to publish slow logs to CloudWatch Logs?

I want to resolve the error that I receive in AWS CloudFormation when I try to publish slow logs to Amazon CloudWatch Logs. The error is: "The Resource Access Policy specified for the CloudWatch Logs log group /aws/aes/domains/search/search-logs does not grant sufficient permissions for Amazon Elasticsearch Service to create a log stream."

Answer: "I want to resolve the error that I receive in AWS CloudFormation when I try to publish slow logs to Amazon CloudWatch Logs. The error is: "The Resource Access Policy specified for the CloudWatch Logs log group /aws/aes/domains/search/search-logs does not grant sufficient permissions for Amazon Elasticsearch Service to create a log stream."Short descriptionTo resolve this error, use a separate policy at the log group level to allow Amazon Elasticsearch Service (Amazon ES) to push logs to CloudWatch Logs. Then, use AccessPolicies in the AWS::Elasticsearch::Domain resource to set permissions for Amazon ES domains.The following steps show you how to publish slow logs to CloudWatch with CloudFormation by using an AWS Lambda-backed custom resource created in Python 3.6. The custom resource triggers a Lambda function, which triggers the PutResourcePolicy API to publish slow logs.Note: When CloudFormation enables log publishing to CloudWatch, the AWS::Logs::LogGroup resource doesn't have a property to assign a resource access policy. The resource access policy specified for the CloudWatch Logs log group should grant sufficient permissions for Amazon ES to publish the log stream. You can't create an access policy permission directly using a CloudFormation resource. This is because the PutResourcePolicy API call for the AWS::Logs::LogGroup resource isn't supported by CloudFormation.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.The following CloudFormation template uses a custom resource to get the name of the log group. Then, the template applies the policy that allows the Amazon ES service to make API calls on the log group.1.    Create a CloudFormation template called ESlogsPermission.yaml:Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.Permission is hereby granted, free of charge, to any person obtaining a copy of thissoftware and associated documentation files (the "Software"), to deal in the Softwarewithout restriction, including without limitation the rights to use, copy, modify,merge, publish, distribute, sublicense, and/or sell copies of the Software, and topermit persons to whom the Software is furnished to do so.THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR APARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHTHOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTIONOF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THESOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.AWSTemplateFormatVersion: 2010-09-09Description: AWS cloudFormation template to publish slow logs to Amazon CloudWatch Logs.Parameters:  LogGroupName:    Type: String    Description: Please don't change the log group name while updating  ESDomainName:    Description: A name for the Amazon Elastic Search domain    Type: String  LambdaFunctionName:    Description: Lambda Function Name    Type: StringResources:  AwsLogGroup:    Type: 'AWS::Logs::LogGroup'    Properties:      LogGroupName: !Ref LogGroupName  LambdaLogGroup:    Type: 'AWS::Logs::LogGroup'    Properties:      LogGroupName: !Sub '/aws/lambda/${LambdaFunctionName}'  LambdaExecutionRole:    Type: 'AWS::IAM::Role'    Properties:      AssumeRolePolicyDocument:        Version: 2012-10-17        Statement:          - Effect: Allow            Principal:              Service:                - lambda.amazonaws.com            Action:              - 'sts:AssumeRole'      Path: /      Policies:        - PolicyName: root1          PolicyDocument:            Version: 2012-10-17            Statement:              - Effect: Allow                Action:                  - 'logs:CreateLogStream'                  - 'logs:PutLogEvents'                Resource: !Sub >-                  arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/lambda/${LambdaFunctionName}:log-stream:*        - PolicyName: root2          PolicyDocument:            Version: 2012-10-17            Statement:              - Effect: Allow                Action:                  - 'logs:CreateLogGroup'                Resource:                  - !Sub >-                    arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/lambda/${LambdaFunctionName}                  - !Sub >-                    arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/${LogGroupName}              - Effect: Allow                Action:                  - 'logs:PutResourcePolicy'                  - 'logs:DeleteResourcePolicy'                Resource: !Sub 'arn:aws:logs:${AWS::Region}:${AWS::AccountId}:*'  logGroupPolicyFunction:    DependsOn: LambdaLogGroup    Type: 'AWS::Lambda::Function'    Properties:      FunctionName: !Ref LambdaFunctionName      Code:        ZipFile: >          import urllib3          import json          import boto3          http = urllib3.PoolManager()          SUCCESS = "SUCCESS"          FAILED = "FAILED"          def send(event, context, responseStatus, responseData,          physicalResourceId=None, noEcho=False):              responseUrl = event['ResponseURL']              print(responseUrl)              responseBody = {}              responseBody['Status'] = responseStatus              responseBody['Reason'] = 'See the details in CloudWatch Log Stream: ' + context.log_stream_name              responseBody['PhysicalResourceId'] = physicalResourceId or context.log_stream_name              responseBody['StackId'] = event['StackId']              responseBody['RequestId'] = event['RequestId']              responseBody['LogicalResourceId'] = event['LogicalResourceId']              responseBody['NoEcho'] = noEcho              responseBody['Data'] = responseData              json_responseBody = json.dumps(responseBody)              print("Response body:\n" + json_responseBody)              headers = {                  'content-type' : '',                  'content-length' : str(len(json_responseBody))              }              try:                  response = http.request('PUT',responseUrl,body=json_responseBody.encode('utf-8'),headers=headers)                  print("Status code: " + response.reason)              except Exception as e:                  print("send(..) failed executing requests.put(..): " + str(e))          def handler(event, context):              logsgroup_policy_name=event['ResourceProperties']['CWLOGS_NAME']              cw_log_group_arn=event['ResourceProperties']['CWLOG_ARN']              cwlogs = boto3.client('logs')              loggroup_policy={                  "Version": "2012-10-17",                  "Statement": [{                  "Sid": "",                  "Effect": "Allow",                  "Principal": { "Service": "es.amazonaws.com"},                  "Action":[                  "logs:PutLogEvents",                  " logs:PutLogEventsBatch",                  "logs:CreateLogStream"                      ],                  'Resource': f'{cw_log_group_arn}'                  }]                  }              loggroup_policy = json.dumps(loggroup_policy)              if(event['RequestType'] == 'Delete'):                  print("Request Type:",event['RequestType'])                  cwlogs.delete_resource_policy(                  policyName=logsgroup_policy_name                 )                  responseData={}                  send(event, context, SUCCESS, responseData)              elif(event['RequestType'] == 'Create'):                  try:                      cwlogs.put_resource_policy(                      policyName = logsgroup_policy_name,                      policyDocument = loggroup_policy                       )                      responseData={}                      print("Sending response to custom resource")                      send(event, context, SUCCESS, responseData)                  except Exception as  e:                      print('Failed to process:', e)                      send(event, context, FAILED, responseData)              elif(event['RequestType'] == 'Update'):                  try:                      responseData={}                      print("Update is not supported on this resource")                      send(event, context, SUCCESS, responseData)                  except Exception as  e:                      print('Failed to process:', e)                      send(event, context, FAILED, responseData)      Handler: index.handler      Role: !GetAtt         - LambdaExecutionRole        - Arn      Runtime: python3.6  logGroupPolicycustomresource:    Type: 'Custom::LogGroupPolicy'    Properties:      ServiceToken: !GetAtt         - logGroupPolicyFunction        - Arn      CWLOGS_NAME: !Ref LogGroupName      CWLOG_ARN: !GetAtt         - AwsLogGroup        - Arn  ElasticsearchDomain:    Type: 'AWS::Elasticsearch::Domain'    DependsOn: logGroupPolicycustomresource    Properties:      DomainName: !Ref ESDomainName      ElasticsearchVersion: '6.2'      EBSOptions:        EBSEnabled: true        VolumeSize: 10        VolumeType: gp2      LogPublishingOptions:        SEARCH_SLOW_LOGS:          CloudWatchLogsLogGroupArn: !GetAtt             - AwsLogGroup            - Arn          Enabled: true2.    To launch a CloudFormation stack with the ESlogsPermission.yaml file, use the CloudFormation console or the following AWS CLI command:aws cloudformation create-stack --stack-name yourStackName --template-body file://yourTemplateName --parameters ParameterKey=LogGroupName,ParameterValue=Your-LogGroup-Name, ParameterKey=ESDomainName,ParameterValue=Your-ES-Name --capabilities CAPABILITY_NAMED_IAM --region yourRegionNote: Replace yourStackName, yourTemplateName, Your-LogGroup-Name, Your-ES-Name, and yourRegion with your values.The CloudFormation template does the following for you:1.    Creates a log group.2.    Creates a Lambda function. The Lambda function gets the log group name from the Parameters section of the CloudFormation template by using a custom resource. The Lambda function calls the PutResourcePolicy API for the log group name. The log group must have a policy to allow the Amazon ES domain to put the logs.3.    Creates a Lambda-backed custom resource to invoke the Lambda function created in step 2. The custom resource helps apply PutResourcePolicy on the log group Amazon Resource Name (ARN) so that Amazon ES can stream logs. In the template, CloudFormation uses a custom resource to create an Amazon ES domain with the LogPublishingOption.Follow"


Question: How is an Amazon EBS io2 Block Express volume different from io1 and io2 volumes?

I don't know how Amazon Elastic Block Store (Amazon EBS) io2 Block Express volumes differ from io1 and io2 volumes.

Answer: "I don't know how Amazon Elastic Block Store (Amazon EBS) io2 Block Express volumes differ from io1 and io2 volumes.Resolutionio1, io2, and io2 Block Express are all Provisioned IOPS SSD volumes. However, io2 Block Express volumes can deliver higher throughput and IOPS and support larger storage capacity. For more information on each volume type, see the chart under Provisioned IOPS SSD (io1 and io2) volumes.The following Amazon Elastic Compute Cloud (Amazon EC2) instance types support io2 Block Express volumes:c7gc6inm6inm6idnm7gr5br6inr6idnr7gtrn1x2idnx2iednWhen you attach an io2 volume to these Amazon EC2 instance types, the volume automatically becomes an io2 Block Express volume.The price for Amazon EBS volume types depends on storage and IOPS. The price for storage between the volume types is the same. However, the price for IOPS varies depending on the number of IOPS that you provision. For more information, see Amazon EBS pricing, and choose the AWS Region that you're in from the Region dropdown list.Follow"


Question: Why is an Amazon EMR step running even though my application on the YARN completed?

An Amazon EMR step is still in the RUNNING state even though the respective Apache Spark or YARN application completed.

Answer: "An Amazon EMR step is still in the RUNNING state even though the respective Apache Spark or YARN application completed.ResolutionUse one of the following methods to resolve the issue:Validate the status of respective YARN application and then end the step.Cancel the Step ID manually using the AWS Command Line Interface (AWS CLI).Validate the status of the YARN application and then end the step1.    Identify the YARN applicationId from the step logs stderr file. For more information, see How do I troubleshoot a failed step in Amazon EMR?2.    Connect to the primary node using SSH.3.    Use the following YARN command to find the state of the YARN application. In the following example command, replace application_id with your application ID. An example application ID is application_1234567891011_001.yarn application -status application_idOr, use the following YARN command to list all applications:yarn application -list -appStates ALL4.    Check the output of the preceding command for the state of the application.Application-States: [NEW, NEW_SAVING, SUBMITTED, ACCEPTED, RUNNING, FINISHED, FAILED, KILLED]The following is example output of an application that completed successfully:Progress : 100%State : FINISHEDFinal-State : SUCCEEDEDIf the output of the preceding command has the states FINISHED, FAILED, or KILLED, then the YARN application is completed.If the application status is NEW, NEW_SAVING, SUBMITTED, ACCEPTED, or RUNNING then the YARN application is still running. Wait for the application to complete or end the application to cancel the step.7.    Run the following command to end the application. In the following example command, replace application_id with your application ID. An example application ID is application_1234567891011_001.yarn application -kill application_id8.    Check the status of the Amazon EMR step again after ending the application.Cancel the Amazon EMR step manually 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.1.    Use the describe-step command to view the step's status. In the following command, replace cluster-id and step-id with the correct values for your use case.aws emr describe-step --cluster-id j-xxxxxxxxxxxxx --step-ids s-xxxxxxxx2.    Use the cancel-steps command to cancel the step. In the following command, replace cluster-id and step-id with the correct values for your use case.aws emr cancel-steps --cluster-id j-xxxxxxxxxxxxx \--step-ids s-3M8DXXXXXXXXX \--step-cancellation-option SEND_INTERRUPTFor more information, see Canceling steps.Follow"


Question: How do I resolve "403 ERROR - The request could not be satisfied. Bad Request" in CloudFront?

Amazon CloudFront is returning the error message "403 ERROR - The request could not be satisfied. Bad Request."

Answer: "Amazon CloudFront is returning the error message "403 ERROR - The request could not be satisfied. Bad Request."Short descriptionThe error message "403 ERROR - The request could not be satisfied. Bad Request." is from the client. This error can occur due to one of the following reasons:The request is initiated over HTTP, but the CloudFront distribution is configured to allow only HTTPS requests. To resolve this issue, follow the steps in the Allow HTTP requests Resolution section.The requested alternate domain name (CNAME) isn't associated with the CloudFront distribution. To resolve this issue, follow the steps in the Associate a CNAME with a distribution Resolution section.Note: This resolution is for troubleshooting the error when you own the application or website that uses CloudFront to serve content to end users. If you receive this error when trying to view an application or access a website, then contact the provider or website owner for assistance.For information on troubleshooting other types of 403 errors, see How do I troubleshoot 403 errors from CloudFront?ResolutionAllow HTTP requestsFollow these steps:Open the Amazon CloudFront console.Choose the distribution that's returning the Bad Request error.Choose the Behaviors tab.Choose the behavior that matches the request. Then, choose Edit.For Viewer Protocol Policy, choose either HTTP and HTTPS or Redirect HTTP to HTTPS.Note: HTTP and HTTPS allows connections on both HTTP and HTTPS. Redirect HTTP to HTTPS automatically redirects HTTP requests to HTTPS.Choose Save Changes.Associate a CNAME with a distributionFollow these steps:Open the Amazon CloudFront console.Choose the distribution that's returning the Bad Request error.Choose the General tab.Under Settings, choose Edit.For Alternate Domain Names (CNAMEs), select Add Item.Enter the CNAME that you want to associate with the CloudFront distribution.Under Custom SSL certificate, choose the certificate that covers the domain. For more information, see How do I configure my CloudFront distribution to use an SSL/TLS certificate?Note: An SSL certificate is required to associate a CNAME with a distribution. For more information see, Requirements for using alternate domain names.Choose Save changes.Related informationHow CloudFront processes HTTP and HTTPS requestsHow do I resolve "403 Error - The request could not be satisfied. Request Blocked" in CloudFront?502 and 494 error: The request could not be satisfied by CloudFrontFollow"


Question: How can I specify multiple Amazon S3 object prefixes for my Snowball export job?

"I want to specify multiple Amazon Simple Storage Service (Amazon S3) object key name prefixes for my AWS Snowball export job. However, when I create a Snowball export job with multiple prefixes, I see that only some files in the prefix range are copied."

Answer: "I want to specify multiple Amazon Simple Storage Service (Amazon S3) object key name prefixes for my AWS Snowball export job. However, when I create a Snowball export job with multiple prefixes, I see that only some files in the prefix range are copied.ResolutionSnowball export jobs support only one prefix range per S3 bucket. To copy all objects across multiple prefixes, you must specify the range to cover all the object key name prefixes that you want to copy. If you're using the AWS Command Line Interface (AWS CLI) to create an export job, then you must confirm that the BeginMarker and EndMarker that you specify within the KeyRange include all the prefixes that you want to copy.Note: The AWS CLI doesn't return an error when you specify multiple values for BeginMarker or EndMarker. However, doing so results in an incomplete copy operation.If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.If the prefix range (key range) that you specify results in an incomplete copy operation, you can do either of the following:Copy the remaining objects to another S3 bucket. You can choose to use the whole bucket to export the remaining data. Or, you can choose to export the remaining objects to a prefix range using a single value for BeginMarker or EndMarker. You're charged for the PUT, COPY, and LIST requests.If you can't copy the remaining objects to another S3 bucket, then you must cancel the incomplete export job. Then, create another export job to copy the remaining objects or prefixes. For example, create two export jobs (or more as needed) to include the desired objects or prefixes.Warning: This option costs more than copying the remaining objects to another bucket.Related informationUsing export rangesAmazon S3 pricingAWS Snowball pricingFollow"


Question: How do I deploy code from a CodeCommit repository to an Elastic Beanstalk environment?

I want to use AWS CodeCommit to deploy incremental code updates to an AWS Elastic Beanstalk environment without re-uploading my entire project.

Answer: "I want to use AWS CodeCommit to deploy incremental code updates to an AWS Elastic Beanstalk environment without re-uploading my entire project.ResolutionYou can use the Elastic Beanstalk Command Line Interface (EB CLI) to deploy your application directly from a CodeCommit repository.Install the EB CLI.Initialize a local Git repository.Create a CodeCommit repository.Note: You can also use the EB CLI to configure additional branches. Then, you can use an existing repository to deploy your code to your Elastic Beanstalk environment.Deploy your code from the CodeCommit repository.Related informationManaging environmentsFollow"


Question: How can I identify what is blocking a query on a DB instance that is running Amazon RDS PostgreSQL or Aurora PostgreSQL?

"I tried to run a query on a DB instance that is running Amazon Relational Database Service (Amazon RDS) PostgreSQL or Amazon Aurora PostgreSQL. But the query was blocked, even though no other queries were executing at the same time. Why was the query blocked, and how do I resolve this issue?"

Answer: "I tried to run a query on a DB instance that is running Amazon Relational Database Service (Amazon RDS) PostgreSQL or Amazon Aurora PostgreSQL. But the query was blocked, even though no other queries were executing at the same time. Why was the query blocked, and how do I resolve this issue?ResolutionMost often, blocked queries are caused by uncommitted transactions. Uncommitted transactions can cause new queries to be blocked, to sleep, and to eventually fail when they exceed the lock wait timeout or the statement timeout. To resolve this issue, first identify the blocking transaction, and then stop the blocking transaction.1.    Identify the current state of the blocked transaction by running the following query against the pg_stat_activity table:SELECT * FROM pg_stat_activity WHERE query iLIKE '%TABLE NAME%' ORDER BY state;Note: Replace TABLE NAME with your own table name or condition.If the value of the wait_event_type column is Lock, the query is blocked by other transactions or queries. If the wait_event_type column has any other value, there is a performance bottleneck with resources such as CPU, storage, or network capacity. To resolve performance bottlenecks, tune the performance of your database, for example, by adding indexes, rewriting queries, or executing vacuum and analyze. For more information, see Best Practices for Working with PostgreSQL.If you enabled Performance Insights on your DB instance, you can also identify blocked transactions by viewing the DB load that is grouped by wait event, hosts, SQL queries, or users. For more information, see Using Amazon RDS Performance Insights.2.    If the value of the wait_event_type column is Lock, then you can identify the cause of the blocked transaction by running the following:SELECT blocked_locks.pid     AS blocked_pid,       blocked_activity.usename  AS blocked_user,       blocked_activity.client_addr as blocked_client_addr,       blocked_activity.client_hostname as blocked_client_hostname,       blocked_activity.client_port as blocked_client_port,       blocked_activity.application_name as blocked_application_name,       blocked_activity.wait_event_type as blocked_wait_event_type,       blocked_activity.wait_event as blocked_wait_event,       blocked_activity.query    AS blocked_statement,       blocking_locks.pid     AS blocking_pid,       blocking_activity.usename AS blocking_user,       blocking_activity.client_addr as blocking_user_addr,       blocking_activity.client_hostname as blocking_client_hostname,       blocking_activity.client_port as blocking_client_port,       blocking_activity.application_name as blocking_application_name,       blocking_activity.wait_event_type as blocking_wait_event_type,       blocking_activity.wait_event as blocking_wait_event,       blocking_activity.query   AS current_statement_in_blocking_process FROM  pg_catalog.pg_locks         blocked_locks    JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid    JOIN pg_catalog.pg_locks         blocking_locks         ON blocking_locks.locktype = blocked_locks.locktype        AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE        AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation        AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page        AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple        AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid        AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid        AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid        AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid        AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid        AND blocking_locks.pid != blocked_locks.pid    JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid   WHERE NOT blocked_locks.granted ORDER BY blocked_activity.pid;3.    Review the columns that have a blocking prefix. In the following example table that was generated by this query, you can see that the blocked transaction is running on the 27.0.3.146 host and using psql:blocked_pid                           | 9069blocked_user                          | masterblocked_client_addr                   | 27.0.3.146blocked_client_hostname               |blocked_client_port                   | 50035blocked_application_name              | psqlblocked_wait_event_type               | Lockblocked_wait_event                    | transactionidblocked_statement                     | UPDATE test_tbl SET name = 'Jane Doe' WHERE id = 1;blocking_pid                          | 8740blocking_user                         | masterblocking_user_addr                    | 27.0.3.146blocking_client_hostname              |blocking_client_port                  | 26259blocking_application_name             | psqlblocking_wait_event_type              | Clientblocking_wait_event                   | ClientReadcurrent_statement_in_blocking_process | UPDATE tset_tbl SET name = 'John Doe' WHERE id = 1;Tip: Use blocking_user, blocking_user_addr, and blocking_client_port to help identify which sessions are blocking transactions.Important: Before terminating transactions, evaluate the potential impact that each transaction has on the state of your database and your application.4.    After reviewing the potential impact of each transaction, stop the transactions by running the following query:SELECT pg_terminate_backend(PID);Note: Replace PID with blocking_pid of the process that you identified in step 3.Related informationPostgreSQL documentation for Viewing locksPostgreSQL documentation for Server signaling functionsPostgreSQL documentation for wait_event descriptionPostgreSQL Wiki for Lock monitoringAmazon Aurora PostgreSQL eventsFollow"


Question: How do I avoid asymmetry in route-based VPN with static routing?

I want to avoid asymmetric routing in route-based VPN that's configured for static routing.

Answer: "I want to avoid asymmetric routing in route-based VPN that's configured for static routing.Short descriptionAWS Site-to-Site VPN provides two endpoints per VPN connection to reach the same destination network. AWS uses either one of the active tunnels to route traffic to the same destination.VPN tunnels are usually hosted on "stateful" firewalls. The firewall devices expect a packet to use the same tunnel interface to send and receive traffic. Asymmetric routing occurs when the packet enters Amazon Virtual Private Cloud (Amazon VPC) through one tunnel and exits through the other tunnel on the same Site-to-Site VPN. When the packet returns through another tunnel interface, it doesn't match the "stateful" session and therefore gets dropped.ResolutionYou don’t need to create a new VPN with dynamic routing to address the problem of asymmetric routing. Instead, continue to use static routing after you’ve made changes to reflect the dynamic routing logic, as shown below.PrerequisiteConfirm that you have asymmetric routing by checking the Amazon CloudWatch metrics:View metrics for each tunnelIf you have only one VPN connection with Active/Active configuration:Open the CloudWatch console.In the navigation pane, choose Metrics.Under All metrics, choose the VPN metric namespace.Select VPN Tunnel Metrics.Select the CloudWatch metrics TunnelDataIn and TunnelDataOut. If there's asymmetric routing, one tunnel has data points for the metric TunnelDataIn. The second tunnel has data points for the metric TunnelDataOut.View metrics for the whole VPN connection (aggregate metrics)If you have multiple VPN connections:Open the CloudWatch console.In the navigation pane, choose Metrics.Under All metrics, choose the VPN metric namespace.Select VPN Connection Metrics.Select the CloudWatch metrics TunnelDataIn and TunnelDataOut. If there's asymmetric routing, one connection has data points for the metric TunnelDataIn. The other connection has data points for the metric TunnelDataOut.For more information on tunnel metrics, see Monitoring VPN tunnels using CloudWatch.Asymmetric routing scenariosReview the following options to avoid asymmetric routing in these scenarios:A single VPN connection configured as Active/ActiveTo avoid asymmetric routing:Use the IPsec aggregate feature if the customer gateway supports it. For more information, see IPsec aggregate for redundancy and tunnel load-balancing on the Fortinet website.If the customer gateway supports asymmetric routing, then make sure that asymmetric routing is turned on, on the virtual tunnel interfaces.If customer gateway doesn't support asymmetric routing, then make sure that the VPN setting is Active/Passive. This configuration identifies one tunnel as UP and the second tunnel as DOWN. In this setting, traffic from AWS to the on-premises network traverses only through the tunnel in the UP state. For more information, see How do I configure my Site-to-Site VPN to prefer tunnel A over tunnel B?Two VPN connections (VPN-Pry and VPN-Sec) connect to the same VPCIn this scenario, VPN connections connect to the same Amazon VPC, using the same virtual private gateway.Note: This scenario applies only to VPN connections with the virtual private gateway.Both connections:Use static routingAdvertise the same on-premises prefixes. For example, 10.170.0.0/20 and 10.167.0.0/20Connect to the same VPC through the virtual private gatewayHave different customer gateway public IPsImplement the following to avoid asymmetric routing:Static routes for VPN-Pry (primary connection):10.170.0.0/2110.170.8.0/2110.167.0.0/2110.167.8.0/21Static routes for VPN-Sec (secondary connection):10.170.0.0/2010.167.0.0/20In these settings, AWS chooses VPN-Pry as the preferred connection over VPN-Sec. AWS uses the longest prefix match in your route table that matches the traffic to determine how to route the traffic.Note: If your customer gateway doesn’t have asymmetric routing in this scenario, then configure each VPN setting as Active/Passive. Doing so identifies one tunnel as active per VPN connection. Traffic fails over to the active tunnel of the secondary connection if both tunnels of the active connection are down.For more information on VPN route priority, see Route tables and VPN route priority.Follow"


Question: How do I change the subnet mask for the default subnet of my default Amazon VPC?

I want to change the subnet mask for the default subnet of my default virtual private cloud (VPC) in Amazon Virtual Private Cloud (Amazon VPC).

Answer: I want to change the subnet mask for the default subnet of my default virtual private cloud (VPC) in Amazon Virtual Private Cloud (Amazon VPC).Short descriptionYou can delete thedefault subnet for your default VPC and replace it with customized configurations.ResolutionDelete the default subnet for your default Amazon VPC in an AWS Region.Create a new subnet with your preferred subnet mask size. Be sure that the new subnet is part of your default VPC in the same AWS Region.Note: The first four IP addresses and the last IP address in each subnet CIDR block aren't available for your use. These IP addresses can't be assigned to an instance.Related informationDelete your default subnets and default VPCHow Amazon VPC worksFollow


Question: How do I increase my security group rule quota in Amazon VPC?

I've reached the quota for "Rules per security group" or "Security groups per network interface" in my Amazon Virtual Private Cloud (Amazon VPC). How do I increase my security group quota in Amazon VPC?

Answer: "I've reached the quota for "Rules per security group" or "Security groups per network interface" in my Amazon Virtual Private Cloud (Amazon VPC). How do I increase my security group quota in Amazon VPC?ResolutionThe quota for "Security groups per network interface" multiplied by the quota for "Rules per security group" can't exceed 1,000. You can modify the quota for both so that the product of the two doesn't exceed 1,000.For more information on how to modify the default security group quota, see Amazon VPC quotas.Follow"


Question: Why can't I see the instance metrics for my Amazon SageMaker endpoint though I can see the invocation metrics?

"I can see invocation metrics for my Amazon SageMaker endpoint in Amazon CloudWatch. However, instance metrics such as CPUUtilization, MemoryUtilization, and DiskUtilization are missing."

Answer: "I can see invocation metrics for my Amazon SageMaker endpoint in Amazon CloudWatch. However, instance metrics such as CPUUtilization, MemoryUtilization, and DiskUtilization are missing.ResolutionThis happens when the execution role for Amazon SageMaker doesn't have the PutMetricData permission for CloudWatch. To resolve the issue, add "cloudwatch:PutMetricData" to the AWS Identity and Access Management (IAM) policy that's attached to the execution role.To send instance metrics to CloudWatch, instances must assume the execution role. That's why the PutMetricData permission is required for instance metrics.Related informationMonitor Amazon SageMaker with Amazon CloudWatchSageMaker rolesFollow"