Question: Why can't I connect my EMR notebook to the cluster?

I can't connect my Amazon EMR notebook to my EMR cluster.

Answer: "I can't connect my Amazon EMR notebook to my EMR cluster.Short descriptionWhen connecting an EMR notebook to the EMR cluster, you might receive errors similar to the following:Unable to attach to cluster j-XXXXXXXXXXX. Reason: Attaching the workspace(notebook) failed. Internal error.Notebook is not supported in the chosen Availability Zone. Please try using a cluster in another availability zone.Attaching the workspace(notebook) failed. Invalid configuration.Workspace(notebook) is stopped. Cluster j-XXXXXXXXXX does not have JupyterEnterpriseGateway application installed. Please retry with another cluster.Workspace errors: Not able to attached EMR notebook to running cluster. Error starting kernel. HTTP 403: Forbidden (Workspace is not attached to cluster. Click 'Ok' to continue.)ResolutionVerify that the attached cluster is compatible and meets all cluster requirementsCluster requirements for EMR notebooks are as follows:1.    Only clusters created using Amazon EMR release version 5.18.0 and later are supported.2.    Clusters created using Amazon Elastic Compute Cloud (Amazon EC2) instances with AMD EPYC processors aren't supported. For example, m5a.* and r5a.* instance types aren't supported.3.    EMR notebooks work only with clusters created with the VisibleToAllUsers variable set to true. VisibleToAllUsers is set to true by default.4.    The cluster must be launched within an EC2 Amazon Virtual Private Cloud (Amazon VPC). Public and private subnets are supported.5.    EMR notebooks currently support Apache Spark clusters only.6.    For EMR release versions 5.32.0 and later, or 6.2.0 and later, your cluster must be running the Jupyter Enterprise Gateway application.7.    Clusters using Kerberos authentication aren't supported.8.    Clusters integrated with AWS Lake Formation support the installation of notebook-scoped libraries only. Installing kernels and libraries on the cluster isn't supported.9.    Clusters with multiple primary nodes aren't supported.10.    Clusters using Amazon EC2 instances based on AWS Graviton2 aren't supported.For more information, see Cluster requirements.Error: Unable to attach to cluster j-XXXXXXXXXXX. Reason: Attaching the workspace(notebook) failed. Internal errorThis occurs on EMR clusters with Apache Livy impersonation turned on. This means the livy.impersonation.enabled variable is set to true. On Amazon EMR 6.4.0 Livy impersonation is set to true by default. The EMR notebooks feature with Livy user impersonation turned off also have HttpFS turned off by default. This means that the EMR notebook can't connect to clusters that have Livy impersonation turned on. For more information, see Amazon EMR release 6.4.0.To avoid this problem, do the following:You can use any older version or newer version of EMR 6.4.0 where the hadoop-httpfs service is running.-or-Restart the hadoop-httpfs service on cluster by doing the following:1.    Use SSH to connect to the EMR primary node.2.    Run the following command to start the hadoop-httpfs service:sudo systemctl start hadoop-httpfsOr, you can start the hadoop-httpfs service using an EMR step:==========JAR location: command-runner.jarMain class: NoneArguments: bash -c "sudo systemctl start hadoop-httpfs"Action on failure: Continue==========Run the following command to verify the status of HttpFS:$ sudo systemctl status hadoop-httpfs  hadoop-httpfs.service - Hadoop httpfs   Loaded: loaded (/etc/systemd/system/hadoop-httpfs.service; disabled; vendor preset: disabled)   Active: active (running)...3.    Reattach the EMR cluster.Error: Workspace errorsThe following are common workspace errors when trying to connect your EMR cluster to an EMR notebook:Not able to attached EMR notebook to running cluster.Error Starting Kernel.HTTP 403: Forbidden (Workspace is not attached to cluster. Choose 'Ok' to continue.)These errors occur because the AWS root account isn't authorized to attach EMR notebooks to EMR clusters. The root user is considered an unauthorized user to start kernels. If the value of KERNEL_USERNAME appears in the unauthorized_users list, the request to connect fails. For more information, see Security features.To avoid workspace errors, create an AWS Identity and Access Manager (AWS IAM) user, and then attach the cluster to the notebook. For more information, see Creating an IAM user in your AWS account.Follow"


Question: "How do I turn on AWS WAF logging and send logs to CloudWatch, Amazon S3, or Kinesis Data Firehose?"

"I want to turn on logging for AWS WAF and send the logs to Amazon CloudWatch, Amazon Simple Storage Service (Amazon S3), or Amazon Kinesis Data Firehose. How do I turn on AWS WAF logs, and what are the required permissions?"

Answer: "I want to turn on logging for AWS WAF and send the logs to Amazon CloudWatch, Amazon Simple Storage Service (Amazon S3), or Amazon Kinesis Data Firehose. How do I turn on AWS WAF logs, and what are the required permissions?Short descriptionFirst, choose a supported destination for your AWS WAF web ACL. AWS WAF supports the following log destinations:A log group from Amazon CloudWatch LogsAn S3 bucket from Amazon Simple Storage ServiceAmazon Kinesis Data Firehose destinationsBe sure you have the necessary resource permissions to turn on AWS WAF logs. Then, turn on AWS WAF logs using your chosen destination.ResolutionThe following destinations are supported for storing your AWS WAF logs:Amazon CloudWatch LogsTo send the logs to a CloudWatch Logs log group, choose CloudWatch Logs log group as the destination when turning on AWS WAF logs.Either create a new log group or use an existing log group. When turned on, AWS WAF logs are sent to log groups in log streams. You can analyze these logs using Logs Insights. For more information, see What are my options to analyze AWS WAF logs stored in CloudWatch or Amazon S3?Consider the following when using CloudWatch logs:Log group names must start with the prefix aws-waf-logs-.Log groups must be in the same AWS account and Region as your web ACL. For Global web ACLs associated to CloudFront, the log group must be in US East (N. Virginia) Region.Log groups have quotas for log groups when storing logs.Log streams created in log groups have the following format:Region_web-acl-name_log-stream-numberNecessary permissionsThe account turning on the AWS WAF logs using CloudWatch Logs log group, must have the following permissions:wafv2:PutLoggingConfigurationwafv2:DeleteLoggingConfigurationlogs:CreateLogDeliverylogs:DeleteLogDeliverylogs:PutResourcePolicylogs:DescribeResourcePolicieslogs:DescribeLogGroupsThese permissions are necessary to change the web ACL logging configuration, configure log delivery, and to retrieve and edit permissions for a log group. These permissions must be attached to the user that is managing AWS WAF.When these permissions are assigned, AWS automatically adds the following policy in the resource-based policies of CloudWatch Logs. This allows delivery services to push logs to a CloudWatch Logs log group.Note: The account number and Amazon resource name (ARN) will be specific to your account for the following policy.{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "AWSLogDeliveryWrite20150319",      "Effect": "Allow",      "Principal": {        "Service": ["delivery.logs.amazonaws.com"]      },      "Action": [        "logs:CreateLogStream",        "logs:PutLogEvents"      ],      "Resource": ["arn:aws:logs:us-east-1:0123456789:log-group:my-log-group:log-stream:*"],      "Condition": {        "StringEquals": {          "aws:SourceAccount": ["0123456789"]        },        "ArnLike": {          "aws:SourceArn": ["arn:aws:logs:us-east-1:0123456789:*"]        }      }    }  ]}If you don't see logs in your log group, check if the preceding necessary permissions are added to your log group's resource based policy using DescribeResourcePolicies API. You can edit the resource based policy for logs services using PutResourcePolicy.For more information on log group permissions, see Enabling logging from certain AWS services.Amazon S3 bucketTo send the logs to an Amazon S3 bucket, choose S3 bucket as the destination when turning on AWS WAF logs.Web ACLs publish the log files to an S3 bucket at five minute intervals. The maximum file size is 75 megabytes (MB). If the file size exceeds the maximum, then a new file is logged. When logs are turned on, you can analyze them using Amazon Athena. For more information, see Querying AWS WAF logs.S3 bucket names for AWS WAF logging must start with the prefix aws-waf-logs-.Necessary permissionsThe account turning on the AWS WAF logs using an S3 bucket, must have the following permissions:wafv2:PutLoggingConfigurationwafv2:DeleteLoggingConfigurationlogs:CreateLogDeliverylogs:DeleteLogDeliverys3:PutBucketPolicys3:GetBucketPolicyThese permissions are necessary to turn on AWS WAF logging and to configure log delivery for an S3 bucket. They are also needed to retrieve and edit the bucket policy to allow AWS WAF log delivery to an S3 bucket.When these permissions are assigned, the following example policy is automatically added in the Bucket policy to allow delivery of logs to the S3 bucket:Note: The account number and Amazon Resource Name (ARN) are specific to your account for the following policy.{  "Version": "2012-10-17",  "Id": "AWSLogDeliveryWrite20150319",  "Statement": [    {      "Sid": "AWSLogDeliveryAclCheck",      "Effect": "Allow",      "Principal": {        "Service": "delivery.logs.amazonaws.com"      },      "Action": "s3:GetBucketAcl",      "Resource": "arn:aws:s3:::my-bucket",      "Condition": {        "StringEquals": {          "aws:SourceAccount": [            "0123456789"          ]        },        "ArnLike": {          "aws:SourceArn": [            "arn:aws:logs:us-east-1:0123456789:*"          ]        }      }    },    {      "Sid": "AWSLogDeliveryWrite",      "Effect": "Allow",      "Principal": {        "Service": "delivery.logs.amazonaws.com"      },      "Action": "s3:PutObject",      "Resource": "arn:aws:s3:::my-bucket/AWSLogs/account-ID/*",      "Condition": {        "StringEquals": {          "s3:x-amz-acl": "bucket-owner-full-control",          "aws:SourceAccount": [            "0123456789"          ]        },        "ArnLike": {          "aws:SourceArn": [            "arn:aws:logs:us-east-1:0123456789:*"          ]        }      }    }  ]}If you don't see the AWS WAF logs in the S3 bucket, then check if the necessary permissions are present in the bucket policy using GetBucketPolicy API. You can edit the bucket policy using PutBucketPolicy API.To send logs to another AWS account or Region, see How do I send AWS WAF logs to an Amazon S3 bucket in a centralized logging account?Amazon Kinesis Data FirehoseTo send the AWS WAF logs to Kinesis Data Firehose stream, you must create a delivery stream. The delivery stream has different destinations to store logs.Consider the following when using Kinesis Data Firehose:The Kinesis Data Firehose name must start with the prefix aws-waf-logs-.The Kinesis Data Firehose delivery stream must be in the same AWS account and Region as your web ACL. For Global web ACLs associated to CloudFront, the Kinesis Data Firehose must be in the US East (N. Virginia) Region.One AWS WAF log is equivalent to one Kinesis Data Firehose record and is subject to Amazon Kinesis Data Firehose Quotas.Important: If you receive more than 10,000 requests per second, your data is throttled and not all requests are logged. To prevent throttling, you must request an increase in the quota for the Kinesis Data Firehose.Necessary permissionsThe account turning on the AWS WAF logs using the Kinesis Data Firehose destination must have the following permissions:wafv2:PutLoggingConfigurationwafv2:DeleteLoggingConfigurationiam:CreateServiceLinkedRolefirehose:ListDeliveryStreamsFor information about service-linked roles and the iam:CreateServiceLinkedRole permission, see Using service-linked roles for AWS WAF.To create a Kinesis Data Firehose delivery stream, follow these steps:Open the Amazon Kinesis console.For Region, select the AWS Region where you created your web ACL.Note: Select Global if your web ACL is set up for Amazon CloudFront.In the navigation pane, choose Delivery streams.Choose Create delivery stream.For Source, choose Direct PUT.For Destination, choose from the available destinations for Kinesis Firehose.For Delivery stream name, enter a name for your delivery stream starting with aws-waf-logs-.Confirm Data transformation and Record format conversion are both Disabled.Enter the Destination settings based on your destination method chosen in step 6.(Optional) For Buffer hints, compression and encryption, configure to your specifications or keep the default settings.(Optional) For Advanced settings, configure to your specifications or keep the default settings.Review the settings for the delivery stream. If the settings match your specifications, choose Create delivery stream.Turn on AWS WAF logsAfter you decide the destination where you want to send your AWS WAF logs, turn on AWS WAF logging by doing the following:Open the AWS WAF console.For Region, select the AWS Region where you created your web ACL.Note: Select Global if your web ACL is set up for Amazon CloudFront.Select your web ACL.Choose Logging and Metrics, then choose Enable.Choose the Destination of where you want to store the AWS WAF logs from the supported destinations.For Redacted fields, select the fields you want to omit from the logs.For Filter logs, add the filter to control which requests you want to store.Choose Save.Follow"


Question: How do I terminate active resources that I no longer need on my AWS account?

I want to terminate active resources that I no longer need.

Answer: "I want to terminate active resources that I no longer need.ResolutionClosing your account doesn't automatically terminate all your active resources. If you're closing your account, first confirm that all active resources are terminated to prevent unexpected charges.SubscriptionsYou will continue to incur charges for Savings Plans, Reserved Instances, or other Subscriptions even after you close or suspend your account.If you have Reserved Instances (RIs) with a monthly charge on your account, then you're billed for these subscriptions until the plan term ends. This applies to monthly charges such as:Amazon Elastic Compute Cloud (Amazon EC2) RIsAmazon Relational Database Service (Amazon RDS) RIsAmazon Redshift RIsAmazon ElastiCache Reserved Cache NodesAWS can't cancel an RI before the subscription term ends. You can list your Amazon EC2 RIs for sale on the EC2 Reserved Instance Marketplace. For more information, see Sell in the Reserved Instance Marketplace.If you have active AWS Marketplace subscriptions, these subscriptions aren't automatically canceled on account closure. You must first terminate all instances of your software in the subscriptions. Then, cancel subscriptions on the Manage subscriptions page of the AWS Marketplace console.If you signed up for a Savings Plan, then you're charged for the compute usage covered under the Savings Plan until the plan term ends.ResourcesTo find your active resources, see How do I check for active resources that I no longer need on my AWS account?To terminate active resources under different services, do the following:Open the AWS Management Console.Open the console for the service that contains the resources that you want to terminate (for example, Amazon Simple Storage Service). You can find a specific service by entering the service name in the search bar.After opening the service console, terminate all your active resources. Be sure to check each Region where you have allocated resources.Tip: You can change the Region with the Region selector in the navigation bar.To terminate your active resources for some commonly used AWS services, do the following:Amazon EC2To delete active Amazon EC2 instances, see How do I delete or terminate my Amazon EC2 resources?You might be charged for Elastic IP addresses even after you terminate all your EC2 instances. You can stop the charges by releasing the IP address. For more information, see Why am I being billed for Elastic IP addresses when all my Amazon EC2 instances are terminated?Even after terminating your EC2 instances, you will still incur charges for the Amazon Elastic Block Store (Amazon EBS) volumes attached to your EC2 instances. Be sure to delete the Amazon EBS volumes and Amazon EBS snapshots. For more information, see Why am I being charged for EBS when all my instances are stopped?Note: The Amazon EBS root device volumes are automatically deleted when you terminate your EC2 instances.Amazon S3To delete Amazon Simple Storage Service (Amazon S3) objects and buckets, see How do I delete Amazon S3 objects and buckets?Note: Be sure that the Server access logging for your Amazon S3 bucket is deactivated before deleting the objects in the bucket. Otherwise, logs might be immediately written to your bucket after you delete your bucket's objects. For more information, see Turning on Amazon S3 server access logging.If you have an Amazon S3 bucket that was created by AWS Elastic Beanstalk, you must first delete the Bucket Policy. The  Bucket Policy is located in the Permissions section of the bucket properties in the Amazon S3 console. For more information, see Using Elastic Beanstalk with Amazon S3.Note: If you delete a bucket created by Elastic Beanstalk and you have existing applications in the corresponding Region, your applications might not function accurately.Amazon RDSTo delete Amazon RDS Amazon Relational Database Service (Amazon RDS) resources, see Deleting a DB instance.To delete Amazon RDS snapshots, see Deleting a snapshot.To delete retained automated backups of DB instances, see Working with backups.Important: To delete a DB instance or DB snapshot that has deletion protection activated, you must modify the instance and deactivate deletion protection.Amazon LightsailTo delete your active Lightsail resources, see How do I shut down my Amazon Lightsail resources?Other servicesIt's a best practice to delete your active AWS Directory Service directories before account closure. For more information, see How do I delete an AWS Directory Service directory?To terminate resources for other services not listed in this article, see the AWS Documentation for that service.Related informationWhy did I receive a bill after I closed my AWS account?How do I terminate an Amazon EMR cluster?How do I delete or terminate an Amazon ECS service?How do I delete or terminate a Client VPN endpoint or connection on AWS Client VPN?How do I delete a NAT Gateway in Amazon VPC?Follow"


Question: "Why did my Amazon RDS DB instance restart, recover, or failover?"

"I want to know the root cause for the restart, recover, or failover of my Amazon Relational Database Service (Amazon RDS) DB instance."

Answer: "I want to know the root cause for the restart, recover, or failover of my Amazon Relational Database Service (Amazon RDS) DB instance.Short descriptionThe Amazon RDS database instance automatically performs a restart under the following conditions:There is loss of availability in primary Availability Zone or excessive workload due to performance bottleneck and resource contention.There is an underlying infrastructure issue with the primary instance, such as loss of network connectivity to the primary instance, compute unit issue on primary, or storage issue on primary.The DB instance class type is changed as part of the DB instance vertical scaling activity.The underlying host of the RDS DB instance is undergoing software patching during a specific maintenance window. For more information, see Maintaining a DB instance and Upgrading a DB instance engine version.You initiated a manual reboot of the DB instance using the options Reboot or Reboot with failover.When the DB instance shows potential issues and fails to respond to RDS health checks, RDS automatically initiates a Single-AZ recovery for the Single-AZ deployment and a Multi-AZ failover for the Multi-AZ deployment. Then, the DB instance is restarted so that you can resume database operations as quickly as possible without administrative intervention.ResolutionTo identify the cause of the outage, check the following logs and metrics for your RDS DB instance.Amazon RDS eventsTo identify the root cause of an unplanned outage in your instance, view all the Amazon RDS events for the last 24 hours. All the events are registered in the UTC/GMT time by default. To store events a longer time, send the Amazon RDS events to Amazon CloudWatch Events. For more information, see Creating a rule that triggers on an Amazon RDS event. When your instance restarts, you see one of the following messages in RDS event notifications:The RDS instance was modified by customer: This RDS event message indicates that the failover was initiated by an RDS instance modification.Applying modification to database instance class: This RDS event message indicates that the DB instance class type is changed.Single-AZ deployments become unavailable for a few minutes during this scaling operation.Multi-AZ deployments are unavailable during the time that it takes for the instance to failover. This duration is usually about 60 seconds. This is because the standby database is upgraded before the newly sized database experiences a failover. Then, your database is restarted, and the engine performs recovery to make sure that your database remains in a consistent state.The user requested a failover of the DB instance: This message indicates that you initiated a manual reboot of the DB instance using the option Reboot or Reboot with failover.The primary host of the RDS Multi-AZ instance is unhealthy: This reason indicates a transient underlying hardware issue that led to the loss of communication to the primary instance. This issue might have rendered the instance unhealthy because the RDS monitoring system couldn't communicate with the RDS instance for performing the health checks.The primary host of the RDS Multi-AZ instance is unreachable due to loss of network connectivity: This reason indicates that the Multi-AZ failover and database instance restart were caused by a transient network issue that affected the primary host of your Multi-AZ deployment. The internal monitoring system detected this issue and initiated a failover.The RDS Multi-AZ primary instance is busy and unresponsive, the Multi-AZ instance activation started, or the Multi-AZ instance activation completed: The event log shows these messages under the following situations:The primary DB instance is unresponsive.A memory crunch after an excessive memory consumption in the database prevented the RDS monitoring system from contacting the underlying host. Hence the database restarts by our monitoring system as a proactive measure.The DB instance experienced intermittent network issues with the underlying host.The instance experienced a database load. In this case, you might notice spikes in CloudWatch metrics CPUUtilization, DatabaseConnections, IOPS metrics, and Throughput details. You might also notice depletion of Freeablememory.Database instance patched: This message indicates that the DB instance underwent a minor version upgrade during a maintenance window because the setting Auto minor version upgrade is enabled on the instance.CloudWatch metricsView the CloudWatch metrics for your Amazon RDS instance to check if the database load issue caused the outage. For more information, see Monitoring Amazon RDS metrics with Amazon CloudWatch. Check for spikes in the following key metrics that indicate the availability and health status of your RDS instance:DatabaseConnectionsCPUUtilizationFreeableMemoryWriteIOPSReadIOPSReadThroughputWriteThroughputDiskQueueDepthEnhanced MonitoringAmazon RDS delivers metrics from Enhanced Monitoring into your Amazon CloudWatch Logs account. This provides metrics in real time for the operating system that your DB instance runs on. You can view all the system metrics and process information for your DB instances on the console.You can set the granularity for the Enhanced Monitoring feature to 1, 5, 10, 15, 30, or 60.To turn on Enhanced Monitoring for your Amazon RDS instance, see Setting up and enabling Enhanced Monitoring.Performance InsightsThe Performance Insights dashboard contains information related to database performance that can help you analyze and troubleshoot performance issues. You can also identify queries and wait events that consume excessive resources on your DB instance. Performance Insights collects data at the database level and displays the data on the Performance Insights dashboard. For more information, see Monitoring DB load with Performance Insights on Amazon RDS. When an increase in resource consumption is generated from the application side, use the Support SQL ID from your Performance Insights dashboard and match it to the corresponding query. It's a best practice to use this information to tune the performance of the query and optimize your workload using the guidance of your DBA:Open the Amazon RDS console.In the navigation pane, choose Performance insights.On the Performance Insights page, select your DB instance. You can view the Performance Insights dashboard for this DB instance.Select the time frame when the issue occurred.Choose the Top SQL tab.Choose the settings icon, and then turn on Support ID.Choose Save.RDS database logsTo troubleshoot the cause of the outage for your Amazon RDS DB instance, you can view, download, or watch database log files using the Amazon RDS console or Amazon RDS API operations. You can also query the database log files that are loaded into database tables. For more information, see Monitoring Amazon RDS log files.Keep the following best practices in mind when dealing with RDS instance outages:Enable Multi-AZ deployment on your instance to reduce downtime during an outage. With a Multi-AZ deployment, RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone or two readable standbys. For more information, see Amazon RDS Multi-AZ.Adjust the DB instance maintenance window according to your preference. The DB instance is unavailable during this time only if the system changes, such as a change in DB instance class, are being applied and require an outage, and for only the minimum amount of time required to make the necessary changes. For more information, see Maintaining a DB instance. If you don’t want your instances to go through automatic minor version upgrades, you can turn off this option. For more information, see Automatically upgrading the minor engine version.Be sure that you have enough resources allocated to your database to run queries. With Amazon RDS, the amount of resources allocated depends on the instance type. Also, certain queries, such as stored procedures, might take an unlimited amount of memory. Therefore, if the instance restarts frequently due to lack of resources, consider scaling up your database instance class to keep up with the increasing demands of your applications.To avoid instance throttling, configure Amazon CloudWatch alarms on RDS key metrics that indicate the availability and health status of your RDS instances. For example, you can set a CloudWatch alarm on the FreeableMemory metric so that you receive a notification when available memory reaches 95%. It's a best practice to keep at least 5% of the instance memory free. For more information, see How can I filter Enhanced Monitoring CloudWatch logs to generate automated custom metrics for Amazon RDS?To be notified whenever there is a failover on your RDS instance, subscribe to Amazon RDS event notifications. For more information, see How do I create an Amazon RDS event subscription?To optimize database performance, make sure that your queries are properly tuned. Otherwise, you might experience performance issues and extended wait times.To troubleshoot any kind of load in terms of CPU, memory or any other resource crunch. see How can I troubleshoot high CPU utilization for Amazon RDS or Amazon Aurora PostgreSQL?Related informationBest practices for Amazon RDSWhat factors affect my downtime or database performance in Amazon RDS?Why did my Amazon RDS DB instance fail over?How do I minimize downtime during required Amazon RDS maintenance?How do I check running queries and diagnose resource consumption issues for my Amazon RDS or Amazon Aurora PostgreSQL-Compatible Edition DB instance?Follow"


Question: How do I calculate the time for a contact in the queue in Amazon Connect?

I want to calculate the time for a contact being spent in the queue in Amazon Connect.

Answer: "I want to calculate the time for a contact being spent in the queue in Amazon Connect.Short descriptionYou can calculate the time for a contact in the queue in Amazon Connect for active and completed contacts.To calculate time spent in the queue for active contacts, use the following methods:Track Amazon Connect metrics sent to CloudWatch for QueueSize and LongestQueueWaitTimeUse the GetCurrentMetricData API to track CONTACTS_IN_QUEUE and OLDEST_CONTACT_AGEUse Amazon Connect contact events for tracking individual contactsTo calculate time spent in the queue for completed contacts, use the following methods:Track maximum queued time using historical metricsTrack duration using the QueueInfo data in contact records for individual contactsResolutionFor active contactsTrack QueueSize and LongestQueueWaitTime metricsOpen the Amazon CloudWatch console.In the navigation pane, choose Metrics, and then choose All metrics.On the Metrics tab, choose Connect, and then choose Queue metrics.Select the metrics QueueSize and LongestQueueWaitTime.Choose the Graphed metrics tab. Then, for Statistic, choose Maximum.Review both the QueueSize and LongestQueueWaitTime.The QueueSize is the number of contacts in the queue. The LongestQueueWaitTime shows the longest amount of time in seconds that a contact waited in a queue. For more information, see Monitoring your instance using CloudWatch.Tip: You can set a CloudWatch alarm on the LongestQueueWaitTime metric to get a notification if it reaches a certain threshold. For additional information, see Creating an alarm from a metric on a graph.Use the GetCurrentMetricData API to track CONTACTS_IN_QUEUE and OLDEST_CONTACT_AGEFirst, to find the QueueID and InstanceID for the API request parameters, do the following:Log in to your Amazon Connect instance using your access URL (https://alias.awsapps.com/connect/login -or- https://domain.my.connect.aws). You must use the administrator account or the emergency access Amazon Connect instance login.In the navigation menu, choose Routing, and then choose Queues.Choose the name of the queue that you want to review.In the Queue Details, choose the show additional queue information.Find the queue ARN shown as arn:aws:connect:region:account-id:instance/instance-id/queue/queue-id. Make note of the AWS Region, instance-id, and queue-id for the next steps.Then, to run the GetCurrentMetricData API, do the following:1.    Navigate to AWS CloudShell.2.    Run the following AWS Command Line Interface (AWS CLI) command:Note: Replace queue-id, instance-id, and region with your values.aws connect get-current-metric-data --filters Queues=<queue-id> --instance-id <instance-id> --current-metrics Name=CONTACTS_IN_QUEUE,Unit=COUNT Name=OLDEST_CONTACT_AGE,Unit=SECONDS --groupings QUEUE --region <region>Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.You receive an output similar to the following:{    "MetricResults": [        {            "Dimensions": {                "Queue": {                    "Id": "<queue-id>",                    "Arn": "<queue-arn>"                }            },            "Collections": [                {                    "Metric": {                        "Name": "CONTACTS_IN_QUEUE",                        "Unit": "COUNT"                    },                    "Value": 0.0                },                {                    "Metric": {                        "Name": "OLDEST_CONTACT_AGE",                        "Unit": "SECONDS"                    },                    "Value": 0.0                }            ]        }    ],    "DataSnapshotTime": "<The time at which the metrics were retrieved and cached for pagination.>"}Use contact events for tracking individual contacts1.    Open the Amazon EventBridge console.2.    In the navigation pane, choose Rules.3.    Choose Create rule.4.    For Rule type, choose Rule with an event pattern.5.    Choose Next.6.    In the Creation Method, choose Use pattern form.7.    In the Event pattern, select Event source as AWS Services, AWS Service as Amazon Connect, and Event Type as Amazon Connect Contact Event.8.    Under Target1, choose Target type as AWS Service.9.    Under Select a target, choose Lambda function. For the function, do the following:Create a Lambda function with the console, using runtime Python 3.8.For the Lambda function code, use the following:import jsondef lambda_handler(event, context):    # TODO implement    print(event)    return {        'statusCode': 200,        'body': json.dumps('Hello from Lambda!')    }Note: The Lambda function prints all events and is intended for testing. The process to calculate the time spent by a specific contact in a queue must be set up manually.10.    Choose Skip to Review and create, and then choose Create rule.11.    Access the Amazon CloudWatch logs for AWS Lambda to see a near real-time stream of contacts, such as, voice calls, chat, and task events. For example, you can see if a call is queued in your Amazon Connect contact center.Note: Available contact events are INITIATED, CONNECTED_TO_SYSTEM, QUEUED, CONNECTED_TO_AGENT, and DISCONNECTED. Events are released on a best effort basis.12.    To determine the time spent by a specific contact in the queue, first locate the following information:The QUEUED event timestamp for a specific contact ID.The CONNECTED_TO_AGENT event timestamp for the same contact ID.13.    To calculate the time spent by the specific contact in the queue, subtract the QUEUED timestamp from the CONNECTED_TO_AGENT timestamp.For completed contactsTrack queued time using historical metricsTo view the historical metric reports, do the following:Log in to your Amazon Connect instance using your access URL (https://alias.awsapps.com/connect/login -or- https://domain.my.connect.aws).Important: You must log in as a user that has sufficient permissions required to view historical metrics reports.In the navigation menu, choose Analytics and optimization, Historical metrics.Choose the Queues report type.Choose the gear icon.On the Metrics tab, choose Maximum queued time.On the Interval & Time range tab, set the Interval, Time Zone, and Time range.When you're finished customizing your report, choose Apply. The Maximum queued time shows the longest time that a contact spent waiting in the queue for the selected interval and time range.(Optional) To save your report for future use, choose Save, provide a name for the report, and then choose Save.Tip: You can schedule a historical metrics report for future use.You can also use the GetMetricData API to track QUEUED_TIME. The GetMetricData API metrics are available for only a 24 hour duration.Track duration in the QueueInfo using the contact search for individual contactsTo use the contact search, do the following:View a contact record in the UI to open the contact trace record (CTR) that you want to view.If the contact was queued, then the Queue section populates and lists the duration of time the contact spent in the queue. Note: Data retention for CTR is 24 months upon contact initiation.To retain contact data for longer than 24 months, stream the CTRs using the following method:Create an Amazon Kinesis Data Firehose delivery stream or an Amazon Kinesis data stream. Then, activate data streaming in your instance.Note: For an alternate method, see Analyze Amazon Connect contact trace record with Amazon Athena and Amazon QuickSight.Follow"


Question: Why aren't messages that I publish to my Amazon SNS topic getting delivered to my subscribed Amazon SQS queue that has server-side encryption activated?

"When I publish messages to my Amazon Simple Notification Service (Amazon SNS) topic, they're not delivered to my Amazon Simple Queue Service (Amazon SQS) queue. How do I fix this issue if my Amazon SNS topic or Amazon SQS queue—or both—have server-side encryption (SSE) activated?"

Answer: "When I publish messages to my Amazon Simple Notification Service (Amazon SNS) topic, they're not delivered to my Amazon Simple Queue Service (Amazon SQS) queue. How do I fix this issue if my Amazon SNS topic or Amazon SQS queue—or both—have server-side encryption (SSE) activated?Short descriptionYour Amazon SQS queue must use a AWS KMS key (KMS key) that is customer managed. This KMS key must include a custom key policy that gives Amazon SNS sufficient key usage permissions.Note: The required permissions aren't included in the default key policy of the AWS managed KMS key for Amazon SQS, and you can't modify this policy.If your topic has SSE activated, you must also do the following:Configure AWS Key Management (AWS KMS) permissions that allow your publisher to publish messages to your encrypted topic.Resolution1.    Create a new customer managed KMS key with a key policy that has the required permissions for Amazon SNS.2.    Configure SSE for your Amazon SQS queue using the custom KMS key you just created.3.    (If your Amazon SNS topic has SSE activated) Configure AWS KMS permissions that allow your publisher to publish messages to your encrypted topic.For more information, see Activating server-side encryption (SSE) for an Amazon SNS topic with an encrypted Amazon SQS queue subscribed.Note: To troubleshoot other message delivery issues, see Amazon SNS message delivery status.Related informationEncryption at rest for Amazon SQSEncryption at rest for Amazon SNS dataConfiguring server-side encryption (SSE) for an SNS topicUsing key policies in AWS KMSEncrypting messages published to Amazon SNS with AWS KMSFollow"


Question: Why aren't my Amazon S3 objects replicating when I set up replication between my buckets?

"I set up cross-Region replication (CRR) or same-Region replication (SRR) between my Amazon Simple Storage Service (Amazon S3) buckets. However, objects aren't replicating to the destination bucket."

Answer: "I set up cross-Region replication (CRR) or same-Region replication (SRR) between my Amazon Simple Storage Service (Amazon S3) buckets. However, objects aren't replicating to the destination bucket.ResolutionTo troubleshoot S3 objects that aren't replicating to the destination bucket, check the different types of permissions for your bucket. Also, check the public access settings and bucket ownership settings.Tip: Upload an object to the source bucket to test the replication after each configuration change. It's a best practice to make one configuration change at a time to identify any replication setup issues.After you resolve the issues causing replication to fail, there might be objects in the source bucket that weren't replicated. By default, S3 replication doesn't replicate existing objects or objects with a replication status of FAILED or REPLICA. To check the replication status for objects that didn't replicate, see Retrieve list of S3 objects that failed replication. Use S3 batch replication to replicate these objects.Minimum Amazon S3 permissionsConfirm that the AWS Identity Access Management (IAM) role that you used in the replication rule has the correct permissions. If the source and destination buckets are in different accounts, confirm that the destination account's bucket policy grants sufficient permissions to the replication role.The following example shows an IAM policy with the minimum permissions that are required for replication. Based on the replication rule options (example: encryption with SSE-KMS), you might need to grant additional permissions.{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Action": [        "s3:GetReplicationConfiguration",        "s3:ListBucket"      ],      "Resource": [        "arn:aws:s3:::SourceBucket"      ]    },    {      "Effect": "Allow",      "Action": [        "s3:GetObjectVersionForReplication",        "s3:GetObjectVersionAcl",        "s3:GetObjectVersionTagging"      ],      "Resource": [        "arn:aws:s3:::SourceBucket/*"      ]    },    {      "Effect": "Allow",      "Action": [        "s3:ReplicateObject",        "s3:ReplicateDelete",        "s3:ReplicateTags"      ],      "Resource": "arn:aws:s3:::DestinationBucket/*"    }  ]}Note: Replace SourceBucket and DestinationBucket with the names of your S3 buckets.The IAM role must have a trust policy that allows Amazon S3 to assume the role to replicate objects.Example:{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Principal": {        "Service": "s3.amazonaws.com"      },      "Action": "sts:AssumeRole"    }  ]}If the destination bucket is in another account, then the destination bucket policy must grant the following permissions:{  "Version": "2012-10-17",  "Id": "PolicyForDestinationBucket",  "Statement": [    {      "Sid": "Permissions on objects",      "Effect": "Allow",      "Principal": {        "AWS": "arn:aws:iam::SourceBucket-account-ID:role/service-role/source-account-IAM-role"      },      "Action": [        "s3:ReplicateTags",        "s3:ReplicateDelete",        "s3:ReplicateObject"      ],      "Resource": "arn:aws:s3:::DestinationBucket/*"    }  ]}Note: Replace arn:aws:iam::SourceBucket-account-ID:role/service-role/source-account-IAM-role with the ARN of your replication role.Additional Amazon S3 permissionsIf the replication rule is set to Change object ownership to the destination bucket owner, then the IAM role must have the s3:ObjectOwnerOverrideToBucketOwner permissions. This permission is placed on the S3 object resource.Example:{    "Effect":"Allow",         "Action":[       "s3:ObjectOwnerOverrideToBucketOwner"    ],    "Resource":"arn:aws:s3:::DestinationBucket/*"}The destination account must also grant the s3:ObjectOwnerOverrideToBucketOwner permission through the bucket policy:{    "Sid":"1",    "Effect":"Allow",    "Principal":{"AWS":"arn:aws:iam::SourceBucket-account-ID:role/service-role/source-account-IAM-role"},    "Action":["s3:ObjectOwnerOverrideToBucketOwner"],    "Resource":"arn:aws:s3:::DestinationBucket/*"}Note: If the destination bucket's object ownership settings include Bucket owner enforced, then you don't need Change object ownership to the destination bucket owner in the replication rule. This change occurs by default.If the replication rule has delete marker replication activated, then the IAM role must have the s3:ReplicateDelete permissions. If the destination bucket is in another account, then the destination bucket owner must also grant this permission through the bucket policy. For example:{    "Effect":"Allow",    "Action":["s3:ReplicateDelete"],    "Resource":"arn:aws:s3:::DestinationBucket/*"}Note: Replace DestinationBucket with the name of your S3 bucket.After you add the additional S3 permissions to the IAM role, the same permissions must be granted through the bucket policy on the destination bucket:{  "Version": "2012-10-17",  "Id": "PolicyForDestinationBucket",  "Statement": [    {      "Sid": "Stmt1644945277847",      "Effect": "Allow",      "Principal": {        "AWS": "arn:aws:iam::SourceBucket-account-ID:role/service-role/source-account-IAM-role"      },      "Action": [        "s3:ReplicateObject",        "s3:ReplicateTags",        "s3:ObjectOwnerOverrideToBucketOwner",        "s3:ReplicateDelete"      ],      "Resource": "arn:aws:s3:::DestinationBucket/*"    }  ]}AWS KMS permissionsIf a bucket's source objects are encrypted with an AWS KMS key, then the replication rule must be configured to include AWS KMS-encrypted objects.To include objects encrypted with AWS KMS, do the following:1.    Open the Amazon S3 console.2.    Choose the S3 bucket that contains the source objects.3.    On the Management tab, select a replication rule.5.    Choose Edit.6.    Under Encryption, choose Replicate objects encrypted with AWS KMS.7.    Under AWS KMS key for encrypting destination objects, select an AWS KMS key. The default option is to use the AWS KMS key (aws/S3).Examples: Example policies – Using SSE-S3 and SSE-KMS with replicationImportant: If the destination bucket is in a different AWS account, then specify an AWS KMS customer managed key that's owned by the destination account. Don't use the default aws/S3 key. This encrypts the objects with the AWS managed key that's owned by the source account and can't be shared with another account. As a result, the destination account can't access the objects in the destination bucket.AWS KMS additional permissions for cross-account scenariosTo use an AWS KMS key that belongs to the destination account to encrypt the destination objects, the destination account must grant the replication role in the AWS KMS key policy:{    "Sid": "AllowS3ReplicationSourceRoleToUseTheKey",    "Effect": "Allow",    "Principal": {"AWS": "arn:aws:iam::SourceBucket-account-ID:role/service-role/source-account-IAM-role"},    "Action": ["kms:GenerateDataKey", "kms:Encrypt"],    "Resource": "*"}Note: Suppose that you use an asterisk (*) for Resource in the AWS KMS key policy. In this case, the policy grants permission for the AWS KMS key only to the replication role. The policy doesn't allow the replication role to elevate its permissions.Additionally, the source account must add the following minimum permissions to the replication role's IAM policy:{    "Effect": "Allow",    "Action": [        "kms:Decrypt",        "kms:GenerateDataKey"    ],    "Resource": [        "SourceKmsKeyArn"    ]},{    "Effect": "Allow",    "Action": [        "kms:GenerateDataKey",        "kms:Encrypt"    ],    "Resource": [        "DestinationKmsKeyArn"    ]}By default, the AWS KMS key policy grants the root user full permissions to the key. These you can delegate these permissions can to other users in the same account. You can use an IAM policy to grant the replication role permissions to the source KMS key. This is sufficient unless there are deny statements in the source KMS key policy.Explicit deny and conditional allow statementsIf your objects still aren't replicating after you've validated the permissions, then check for any explicit deny statements:Deny statements in the destination bucket policy or AWS KMS key policies that restrict access to the following might cause replication to fail.Specific CIDR rangesVirtual Private Cloud (VPC) endpointsS3 access pointsDeny statements or permissions boundaries that are attached to the IAM role might cause replication to fail.Deny statements in AWS Organizations service control policies (SCPs) that are attached to either the source or destination accounts might cause replication to fail.Tip: Before removing any explicit deny statements, confirm the reason for using the deny and determine whether the statement has an impact on data security.Amazon S3 bucket keys and replication considerationsIf either the source or destination KMS keys grant permissions based on the encryption context, then confirm that the S3 Bucket Keys are turned on for the buckets. If the buckets have Bucket Keys turned on, then the encryption context must be for the bucket level resource:"kms:EncryptionContext:aws:s3:arn": [     "arn:aws:s3:::SOURCE_BUCKET_NAME"     ]"kms:EncryptionContext:aws:s3:arn": [     "arn:aws:s3:::DESTINATION_BUCKET_NAME"     ]Note: Replace SOURCE_BUCKET_NAME and DESTINATION_BUCKET_NAME with the names of your source and destination buckets.    If Bucket Keys aren't turned on for the source or destination buckets, then the encryption context must be the object level resource:"kms:EncryptionContext:aws:s3:arn": [     "arn:aws:s3:::SOURCE_BUCKET_NAME/*"     ]"kms:EncryptionContext:aws:s3:arn": [     "arn:aws:s3:::DESTINATION_BUCKET_NAME/*"     ]Note: Replace SOURCE_BUCKET_NAME and DESTINATION_BUCKET_NAME with the names of your source and destination buckets.Object ACLs and Block Public AccessCheck whether the source and destination buckets are using access control lists (ACLs). If the object includes an ACL that allows public access but the destination bucket is using block public access, then replication fails.Source object ownershipIf the objects in the source bucket were uploaded by another AWS account, then the source account might not have permission to those objects. Check the source bucket to see if ACLs are deactivated. If the source bucket has ACLs deactivated, then the source account is the owner of all objects in the bucket. If the source bucket doesn't have ACLs deactivated, then check to see if object ownership is set to Object owner preferred or Bucket owner preferred. If the bucket is set to Bucket owner preferred, then the source bucket objects must have the bucket-owner-full-control ACL for the bucket owner to become the object owner.The source account can take ownership of all objects in their bucket by deactivating ACLs. Most use cases don't require using ACLs to manage access. It's a best practice to use IAM and bucket policies to manage access to S3 resources. To deactivate ACLs on your S3 bucket, see Controlling ownership of objects and disabling ACLs for your bucket. Be sure to evaluate the current usage of ACLs on your bucket and objects. Your current bucket and IAM policies must grant sufficient permissions so that you can deactivate ACLs without impacting Amazon S3 access.Replication rule filterBe sure that you specified the replication rule filter correctly.If you specify a rule filter with a combination of a key prefix and object tags, S3 performs a logical AND operation to combine these filters. In other words, the rule applies to a subset of objects with a specific key prefix and specific tags.Related informationWalkthroughs: Examples for configuring replicationFollow"


Question: Why can’t I push log data to CloudWatch Logs with the awslogs agent?

I'm unable to push log data to Amazon CloudWatch Logs using the CloudWatch Logs agent (awslogs).

Answer: "I'm unable to push log data to Amazon CloudWatch Logs using the CloudWatch Logs agent (awslogs).ResolutionBefore you begin, confirm that the awslogs agent can connect to the CloudWatch Logs API endpoint.Be sure that your configuration has the following attributes:Internet connectivityValid security group configurationsValid network access control lists (network ACLs)Important: This reference is for the earlier CloudWatch Logs agent that is no longer supported. If you use Instance Metadata Service Version 2 (IMDSv2), then you must use the new unified CloudWatch agent. Even if you aren't using IMDSv2, it's a best practice to use the newer unified CloudWatch agent instead of the logs agent.Fingerprinting issuesReview the header lines of the source log file. You set this file's path when configuring the data to be pushed to CloudWatch.If the first few lines are blank or contain non-event data that stays the same, there might be issues with the log-identifying hash.If the header lines are the same, then update the file_fingerprint_lines option in the agent configuration file. Be sure to specify the lines in each file that are used for generating the identifying hash.Check the awslogs log file for errorsReview the /var/log/awslogs.log log file. Be sure to note any error messages.Permissions errors include:NoCredentialsError: Unable to locate credentials – If you didn't add an AWS Identity and Access Management (IAM) role to the instance, create and attach an IAM role. If you already added an IAM role to the instance, then update the IAM user credentials in the /etc/awslogs/awscli.conf file.ClientError: An error occurred (AccessDeniedException) when calling the PutLogEvents operation: User: arn:aws:iam::012345678910: / is not authorized to perform: logs:PutLogEvents[...] – Configure the IAM role or user with the required permissions for CloudWatch Logs.Timestamp errors include:Fall back to previous event time: {'timestamp': 1492395793000, 'start_position': 17280L, 'end_position': 17389L}, previousEventTime: 1492395793000, reason: timestamp could not be parsed from message. – Confirm that the log events begin with a timestamp. Check if the datetime_format specified in /etc/awslogs/awslogs.conf matches the timestamp format of the log events. Change the datetime_format to match the timestamp format as needed.No file is found with given path ' ' – Update the log file path in the agent configuration file to the correct path.Other awslogs issuesIf logs stopped pushing after a log rotation, check the supported log rotation methods. For more information, see CloudWatch Logs agent FAQ.If logs are pushed briefly only after the awslogs agent is restarted, then check for duplicates in the [logstream] section of the agent configuration file. Each section must have a unique name.If the awslogs.log log file takes up too much disk space, then check the log file for errors, and then correct them. If the log file contains only informational messages, then specify a lower logging level for the logging_config_file option in the agent configuration file.Further troubleshootingFor further troubleshooting, note the instance-id (your instance's ID). Then, collect and review the following based on your configuration.Yum installations:yum version$ yum info awslogs$ yum info aws-cli-plugin-cloudwatch-logs/etc/awslogs/awslogs.conf file/etc/awslogs/awscli.conf fileOther relevant files in /etc/awslogs//var/log/awslogs.log fileScript-based installations:The awslogs version, obtained with the following command:$ /var/awslogs/bin/awslogs-version.sh/var/awslogs/etc/awslogs.conf file/var/awslogs/etc/awscli.conf fileOther relevant files in /var/awslogs/etc//var/log/awslogs.log/var/log/awslogs-agent-setup.logFor rotation-related issues, collect and review:A snippet of the source logsA list of the monitoring target directory's contents. Use the command ls -la with the directory path to obtain this:$ ls -la <Monitoring-Target-Directory-Path>Related informationGetting started with CloudWatch LogsFollow"


Question: How do I use pivoted data after an AWS Glue relationalize transformation?

I want to use the AWS Glue relationalize transform to flatten my data. Which fields can I use as partitions to store the pivoted data in Amazon Simple Storage Service (Amazon S3)?

Answer: "I want to use the AWS Glue relationalize transform to flatten my data. Which fields can I use as partitions to store the pivoted data in Amazon Simple Storage Service (Amazon S3)?Short descriptionThe relationalize transform makes it possible to use NoSQL data structures, such as arrays and structs, in relational databases. The relationalize transform returns a collection of DynamicFrames (a DynamicFrameCollection in Python and an array in Scala). All DynamicFrames returned by a relationalize transform can be accessed through their individual names in Python, and through array indexes in Scala.ResolutionRelationalize the dataThis tutorial uses the following schema:|-- family_name: string|-- name: string|-- gender: string|-- image: string|-- images: array|    |-- element: struct|    |    |-- url: stringUse the following relationalize syntax for Python:# AWS Glue Data Catalog: database and table namesdb_name = "us-legislators"tempDir = "s3://awsexamplebucket/temp_dir/"# Create dynamic frames from the source tablespersons = glueContext.create_dynamic_frame.from_catalog(database=db_name, table_name=tbl_persons)# Relationalize transformationdfc = persons.relationalize("root", tempDir)dfc.select('root_images').printSchema()dfc.select('root_images').show()Use the following relationalize syntax for Scala:// AWS Glue Data Catalog: database and table namesval dbName = "us-legislators"val tblPersons = "persons_json"// Output Amazon S3 temp directoryval tempDir = "s3://awsexamplebucket/temp_dir"val persons: DynamicFrame = glueContext.getCatalogSource(database = dbName, tableName = tblPersons).getDynamicFrame()val personRelationalize = persons.relationalize(rootTableName = "root", stagingPath = tempDir)personRelationalize(2).printSchema()personRelationalize(2).show()Interpret the pivoted dataThis relationalize transform produces two schemas: root and root_images.root:|-- family_name: string|-- name: string|-- gender: string|-- image: string|-- images: longroot_images:|-- id: long|-- index: int|-- images.val.url: stringid: order of the array element (1, 2, or 3)index: index position for each element in an arrayimages.val.url: value for images.val.url in root_imagesThese are the only fields that can be used as partition fields to store this pivoted data in Amazon S3. Specifying root table fields, such as name, doesn't work because those fields don't exist in root_images.Join the relationalized data to get the normalized dataThe id attribute in root_images is the order the arrays (1, 2, or 3) in the dataset. The images attribute in root holds the value of the array index. This means that you must use images and id to join root and root_images. You can run dynamicFrame.show() to verify the order of the arrays and the value of the array index.To join root and root_images:Python:joined_root_root_images = Join.apply(dfc.select('root'), dfc.select('root_images'), 'images', 'id')Scala:val joined_root_root_images = personRelationalize(0).join(keys1 = Seq("images"), keys2 = Seq("id"), frame2 = personRelationalize(1))Store the pivoted dataTo store the pivoted data in Amazon S3 with partitions:Python:datasink4 = glueContext.write_dynamic_frame.from_options(frame = dfc.select('root_images'), connection_type = "s3", connection_options = {"path": outputHistoryDir,"partitionKeys":["id"]}, format = "csv",transformation_ctx = "datasink4")Scala:Note: In the following example, personRelationalize(2) is the root_images pivoted data table.glueContext.getSinkWithFormat(connectionType = "s3",  options = JsonOptions(Map("path" -> paths, "partitionKeys" -> List("id"))),  format = "csv", transformationContext = "").writeDynamicFrame(personRelationalize(2))To store the pivoted data in Amazon S3 without partitions:Python:datasink5 = glueContext.write_dynamic_frame.from_options(frame = dfc.select('root_images'), connection_type = "s3", connection_options = {"path": outputHistoryDir}, format = "csv",transformation_ctx = "datasink5"Scala:Note: In the following example, personRelationalize(2) is the root_images pivoted data table.glueContext.getSinkWithFormat(connectionType = "s3",  options = JsonOptions(Map("path" -> paths)),  format = "csv", transformationContext = "").writeDynamicFrame(personRelationalize(2))After you write the data to Amazon S3, query the data in Amazon Athena or use a DynamicFrame to write the data to a relational database, such as Amazon Redshift.Related informationSimplify querying nested JSON with the AWS Glue relationalize transformCode example: Joining and relationalizing DataFollow"


Question: How do I ingest and visualize the AWS Cost and Usage Report (CUR) into Amazon QuickSight?

I want to ingest the AWS Cost and Usage Report (CUR) from Amazon Simple Storage Service (Amazon S3) into Amazon QuickSight. How do I import and visualize my monthly CUR results?

Answer: "I want to ingest the AWS Cost and Usage Report (CUR) from Amazon Simple Storage Service (Amazon S3) into Amazon QuickSight. How do I import and visualize my monthly CUR results?ResolutionYou can ingest and visualize your AWS Cost and Usage Report (CUR) by doing the following:1.    Create a Cost and Usage Report.2.    Authorize QuickSight to access your Amazon S3 bucket.3.    Open the QuickSight console.4.    Choose Manage Data.5.    Choose New Data Set.6.    Choose S3. This opens the Amazon S3 data source dialog box.7.    In the Amazon S3 data source dialog box, enter a data source name.Important: Make sure that you've set the proper permissions for QuickSight to access the S3 bucket. Otherwise, you can't access any data in QuickSight.8.    In the Upload a Manifest field, choose Upload, or enter the URL of your AWS Cost and Usage Report manifest file like this:s3://awscostusagereport-quicksight/report_path_example/QuickSight/AWS_CUR_QS_ReportName-20200601-20200701-QuickSightManifest.jsonReplace the following variables to indicate the S3 folder and JSON file that you created in Step 1:awscostusagereport-quicksight: Your S3 bucketreport_path_example: The CUR Report path prefixAWS_CUR_QS_ReportName: Your CUR Report name20200601-20200701: The date range of your CUR Report9.    Choose Connect. This creates and opens the new dataset.10.    After you create the new dataset, choose Visualize to display all the data fields in your AWS Cost and Usage Report. For more information about the CUR data field definitions, see the Data dictionary.Additional troubleshootingIf you can't find the QuickSight folder under your S3 bucket, try the following:Allow 24 hours before attempting to regenerate the CUR report and manifest file.Verify that you selected QuickSight for the Enable report data integration for field.If you get a "We can't parse the manifest file as a valid JSON" error message, try the following:Check whether you've correctly authorized QuickSight to access your S3 bucket.Verify that the URL of the manifest file that was copied over is located in the QuickSight folder. Each service folder must have its own manifest file.If you have multiple AWS accounts under the same organization, make sure that you have proper access rights from the management account. This report is available only to the management account owner and any users who are granted access by the management account. For more information, see Consolidated billing for AWS Organizations.Related informationWhat are AWS Cost and Usage Reports?I can't connect to Amazon S3Follow"


Question: Why am I not able to see the Amazon CloudWatch metrics for my AWS Glue ETL job even after I enabled job metrics?

"I've enabled the option to create job metrics for my AWS Glue extract, transform, and load (ETL) job. However, I can't see the job metrics in Amazon CloudWatch."

Answer: "I've enabled the option to create job metrics for my AWS Glue extract, transform, and load (ETL) job. However, I can't see the job metrics in Amazon CloudWatch.Short descriptionAWS Glue sends metrics to CloudWatch every 30 seconds, and the CloudWatch console dashboard is configured to display these metrics every minute. The AWS Glue metrics represent delta values from previously reported values. The metrics dashboard aggregates the 30-second values to obtain a value for the last minute. The job metrics for your job are enabled with the initialization of a GlueContext in the job script. The metrics are updated only at the end of an Apache Spark task. The job metrics represent the aggregate values across all completed Spark tasks.ResolutionIncrease the run time of your AWS Glue job: The CloudWatch metrics are reported every 30 seconds. Therefore, if the run time of your job is less than 30 seconds, then the job metrics aren't sent to CloudWatch. AWS Glue uses the metrics from Spark, and Spark uses the DropWizard metrics library for publishing metrics. To get the AWS Glue metrics, your job must run for at least 30 seconds. Updating your job to process more data can help increase the run time of your job. However, you can use a temporary workaround to see the job metrics. You can increase the run time of your AWS Glue job by including the function time.sleep() in your job. You can include time.sleep() in your job at the start or end of the code based on your use case.**Important:**Using the time.sleep() function is not a coding best practice.For Python:import timetime.sleep(30)For Scala:Thread.sleep(30)Be sure that the job completed the Spark tasks: Job metrics are reported after the Spark tasks are complete. Therefore, check and confirm that the Spark tasks for your job are completed, and the job did not fail.Be sure that GlueContext is initialized in the job script: The GlueContext class in your job script enables writing metrics into CloudWatch. If you're using a custom script that uses only a DataFrame and not a DynamicFrame, the GlueContext class might not be initialized. This might result in the metrics not getting written to CloudWatch. If you're using a custom script, be sure to update your job to initialize the GlueContext class.Be sure that the AWS Glue IAM role has the required permission: Check and confirm that the IAM role attached to the ETL job has the cloudwatch:PutMetricData permission to create metrics in CloudWatch. If you're using a custom role, then be sure that the role has the permission to write the job metrics into CloudWatch.Note: It's a best practice to use the AWS managed policy AWSGlueServiceRole to manage permissions.Related informationMonitoring AWS Glue using Amazon CloudWatch metricsJob monitoring and debuggingFollow"


Question: Why did my Amazon EMR cluster terminate with an "application provisioning failed" error?

My Amazon EMR cluster terminated with an "application provisioning failed" error. What does this error mean and how can I fix it?

Answer: "My Amazon EMR cluster terminated with an "application provisioning failed" error. What does this error mean and how can I fix it?ResolutionYou can see an "application provisioning failed" error when Amazon EMR can't install, configure, or start specified software when it's launching an EMR cluster. The following sections show you how to find and review provisioning logs. They also show you different types of errors and steps you can take to resolve those errors.Review Amazon EMR provisioning logs stored in Amazon S3Amazon EMR provisioning logs are stored in an Amazon Simple Storage Service (Amazon S3) bucket specified at cluster launch. The storage location of the logs uses the following Amazon S3 URI syntax:s3://example-log-location/example-cluster-ID/node/example-primary-node-ID/provision-node/apps-phase/0/example-UUID/puppet.log.gzNote: Replace example-log-location, example-cluster-ID, example-primary-node-ID, and example-UUID with your system's naming.Open the Amazon EMR console. In the navigation pane, choose Clusters. Then, choose the failed EMR cluster to see the cluster details.In the Summary section, choose "Terminated with errors" and note the primary node ID included in the error message.In the Cluster logs section, choose the Amazon S3 location URL to be redirected to the cluster logs in the Amazon S3 console.Navigate to your UUID folder by following this path: node/example-primary-node-ID/provision-node/apps-phase/0/example-UUID/.Note: Replace example-primary-node-ID and example-UUID with your system's naming.In the resulting list, select puppet.log.gz and choose Open to see the provisioning on a new browser tab.Identify the reasons for failures in provisioning logsUnsupported configuration parameters can cause errors. Errors can also be caused by wrong hostnames, incorrect passwords, or general operating system issues. Search logs for related keywords, including "error" or "fail."The following is a list of common error types:Issues connecting to an external metastore with an Amazon Relational Database Service (Amazon RDS) instance.Issues connecting to an external key distribution center (KDC).Issues when starting services, such as YARN ResourceManager and Hadoop NameNode.Issues when downloading or installing applications.S3 logs aren't available.Issues connecting to an external metastore with an Amazon RDS instanceSome Amazon EMR applications, such as Hive, Hue, or Oozie, can be configured to store data in an external database, such as Amazon RDS. When there's an issue with a connection, a message appears.The following is an example error message from Hive:2022-11-26 02:59:36 +0000 /Stage[main]/Hadoop_hive::Init_metastore_schema/Exec[init hive-metastore schema]/returns (notice): org.apache.hadoop.hive.metastore.HiveMetaException: Failed to get schema version.2022-11-26 02:59:36 +0000 /Stage[main]/Hadoop_hive::Init_metastore_schema/Exec[init hive-metastore schema]/returns (notice): Underlying cause: java.sql.SQLNonTransientConnectionException : Could not connect to address=(host=hostname)(port=3306)(type=master) : Socket fail to connect to host:hostname, port:3306. hostname2022-11-26 02:59:36 +0000 /Stage[main]/Hadoop_hive::Init_metastore_schema/Exec[init hive-metastore schema]/returns (notice): SQL Error code: -1To resolve this type of error:Verify that the RDS instance hostname, user, password, and database are correct.Verify that the RDS instance security group inbound rules allow connections from the Amazon EMR primary node security group.Issues connecting to an external KDCAmazon EMR lets you configure an external KDC to add an additional layer of security. You can also create a trust relationship with an Active Directory server. When there's an issue with contacting the KDC or joining a domain, a message appears.The following is an example error message from Puppet:2022-11-26 03:02:01 +0000 Puppet (err): 'echo "${AD_DOMAIN_JOIN_PASSWORD}" | realm join -v -U "${AD_DOMAIN_JOIN_USER}"@"${CROSS_REALM_TRUST_REALM}" "${CROSS_REALM_TRUST_DOMAIN}"' returned 1 instead of one of [0]2022-11-26 03:02:01 +0000 /Stage[main]/Kerberos::Ad_joiner/Exec[realm_join]/returns (err): change from 'notrun' to ['0'] failed: 'echo "${AD_DOMAIN_JOIN_PASSWORD}" | realm join -v -U "${AD_DOMAIN_JOIN_USER}"@"${CROSS_REALM_TRUST_REALM}" "${CROSS_REALM_TRUST_DOMAIN}"' returned 1 instead of one of [0]To resolve this type of error:Verify that the Kerberos realm is spelled correctly.Verify that the KDC administrative password is spelled correctly.Verify that the Active Directory join user and password are spelled correctly.Verify that the Active Directory join user exists in Active Directory and has the correct permissions.Verify that KDC and Active Directory servers are on Amazon EC2. Then, verify that the KDC and Active Directory security group inbound rules allow connections from the Amazon EMR primary node security group.Verify that KDC and Active Directory aren't on Amazon EC2. Then, verify that KDC and Active Directory allow connections from the EMR cluster virtual private cloud (VPC) and subnet.Issues when starting services, such as YARN ResourceManager, Hadoop NameNode, or Spark History ServerAmazon EMR allows the custom configuration of all applications at EMR cluster launch. But, sometimes these configurations prevent services from starting. When there's an issue preventing a service from starting a message appears.The following is an example error message from Spark History Server:2022-11-26 03:34:13 +0000 Puppet (err): Systemd start for spark-history-server failed!journalctl log for spark-history-server:-- Logs begin at Sat 2022-11-26 03:27:57 UTC, end at Sat 2022-11-26 03:34:13 UTC. --Nov 26 03:34:10 ip-192-168-1-32 systemd[1]: Starting Spark history-server...Nov 26 03:34:10 ip-192-168-1-32 spark-history-server[1076]: Starting Spark history-server (spark-history-server):[OK]Nov 26 03:34:10 ip-192-168-1-32 su[1112]: (to spark) root on noneNov 26 03:34:13 ip-192-168-1-32 systemd[1]: spark-history-server.service: control process exited, code=exited status=1Nov 26 03:34:13 ip-192-168-1-32 systemd[1]: Failed to start Spark history-server.Nov 26 03:34:13 ip-192-168-1-32 systemd[1]: Unit spark-history-server.service entered failed state.Nov 26 03:34:13 ip-192-168-1-32 systemd[1]: spark-history-server.service failed.2022-11-26 03:34:13 +0000 /Stage[main]/Spark::History_server/Service[spark-history-server]/ensure (err): change from 'stopped' to 'running' failed: Systemd start for spark-history-server failed!journalctl log for spark-history-server:To resolve this type of error:Verify the service that failed to start. Check if the provided configurations are spelled correctly.Navigate the following path to see the S3 log to investigate the reason for the failure: s3://example-log-location/example-cluster-ID/node/example-primary-node-ID/applications/example-failed-application/example-failed-service.gz.Note: Replace example-log-location, example-cluster-ID, example-primary-node-ID, example-failed-application, and example-failed-service with your system's naming.Issues when downloading or installing applicationsAmazon EMR can install many applications. But, sometimes there's an issue when one application can't be downloaded or installed. This can cause the EMR cluster to fail. When this failure happens, the provisioning logs don't complete. You must review the stderr.gz log instead to find similar messages caused by failed yum installations.The following is an example error message from stderr.gz:stderr.gzError Summary-------------Disk Requirements:  At least 2176MB more space needed on the / filesystem.  2022-11-26 03:18:44,662 ERROR Program: Encountered a problem while provisioningjava.lang.RuntimeException: Amazon-linux-extras topics enabling or yum packages installation failed.To resolve this type of error, increase the root Amazon Elastic Block Store (Amazon EBS) volume during the EMR cluster launch.S3 logs aren't availableAmazon EMR fails to provision applications, and there aren't any logs generated in Amazon S3. In this scenario, it's likely that a network error caused S3 logging to fail.To resolve this type of error:Verify that the Logging option is turned on during the EMR cluster launch. For more information, see Configure cluster logging and debugging.When using a custom AMI, verify that there are no firewall rules interfering with the required Amazon EMR network settings. For more information, see Working with Amazon EMR-managed security groups.When using a custom AMI, check to see if there are any failed primary nodes. Open the Amazon EMR console, and in the navigation pane, choose Hardware to determine if clusters couldn't launch any primary nodes.When using a custom AMI, verify that you're following best practices. For more information, see Using a custom AMI.Related informationEMR cluster failed to provisionFollow"


Question: How do I troubleshoot Application Load Balancer HTTP 403 forbidden errors?

My Application Load Balancer is returning HTTP 403 forbidden errors. How can I troubleshoot this?

Answer: "My Application Load Balancer is returning HTTP 403 forbidden errors. How can I troubleshoot this?ResolutionFollow these troubleshooting steps for your scenario.Important: Before you begin, make sure that you have access logging enabled for your Application Load Balancer. For instructions, see Enable access logging.An AWS WAF web access control list (web ACL) is configured to monitor requests to your Application Load Balancer and it blocked a request.The load balancer sends HTTP errors to access logs and increments the HTTPCode_ELB_4XX_Count metric similar to the following:elb_status_code = 403target_status_code = -actions_executed = wafThis means that the load balancer forwarded the request to AWS WAF to determine whether the request should be forwarded to the target. Then, AWS WAF determined that the request should be rejected. To diagnose the rule configuration, review the AWS WAF logs. For more information, see Managing logging for a web ACL.The Application Load Balancer might have a rule configured with a fixed-response action to provide an HTTP 403 response.Check the access logs for a fixed-response action similar to the following:elb_status_code = 403target_status_code = -actions_executed = fixed-responseThis log indicates that the rule configuration has a fixed-response action to provide an HTTP 403 error.The target responded with an HTTP 403 error and the Application Load Balancer is forwarding this response to the client.Check the access logs for 403 entries for values similar to the following:elb_status_code = 403target_status_code = 403If the target_status_code and elb_status_code values match, then the target application sent the HTTP 403 response. To determine why the target application generated the HTTP 403 forbidden error, check with your application vendor. You can also use the X-Amzn-Trace-Id header to trace requests through the Application Load Balancer. For more information, see How do I trace an Application Load Balancer request using X-Amzn-Trace-Id?Related informationTroubleshoot your Application Load BalancersHTTP 403: ForbiddenFollow"


Question: How do I configure an EC2 Windows instance to allow file downloads using Internet Explorer?

I need to download third-party software from the internet to my Amazon Elastic Compute Cloud (Amazon EC2) Windows instance. The Internet Explorer security configuration is blocking my attempts. How can I enable downloads?

Answer: "I need to download third-party software from the internet to my Amazon Elastic Compute Cloud (Amazon EC2) Windows instance. The Internet Explorer security configuration is blocking my attempts. How can I enable downloads?Short descriptionAmazon Machine Images (AMIs) for Windows Server enable Internet Explorer Enhanced Security Configuration by default, because web browsing isn't a best practice on a server. Internet Explorer Enhanced Security Configuration disables file downloads using Internet Explorer.If you want to download and install tools from the internet, you can change the security configuration to enable downloads.Note: If you enable downloads on your EC2 Windows instance, be sure to download files only from trusted sources. After you download and install the software, it's a best practice to re-enable Internet Explorer Enhanced Security Configuration.ResolutionConnect to your EC2 Windows instance.Open the Windows Start menu, and then open Server Manager.Follow the instructions for the Windows Server version that your EC2 Windows instance is running: Windows Server 2012 R2, Windows Server 2016, or Windows Server 2019: Choose Local Server from the left navigation pane. For IE Enhanced Security Configuration, choose On.Windows Server 2008 R2: Choose Server Manager from the navigation pane. In the Server Summary - Security Information section, choose Configure IE ESC.For Administrators, select Off.For Users, select Off.Choose OK.Close Server Manager.Note: The security configuration change takes effect when you open a new Internet Explorer session. If Internet Explorer is already open, open a new tab. Or, close the browser, and then re-open it.Related informationTutorials for Amazon EC2 instances running Windows ServerTutorial: Get started with Amazon EC2 Windows instancesFollow"


Question: How do I remove the "clientTransferProhibited" status from my Route 53 domain?

The status of my Amazon Route 53 domain is "clientTransferProhibited". How do I remove this status?

Answer: "The status of my Amazon Route 53 domain is "clientTransferProhibited". How do I remove this status?Short descriptionThe domain registries for all generic top-level domains (TLDs) and several geographic TLDs provide the option to lock your domain. Locking a domain prevents someone from transferring the domain to another registrar without your permission. If you enable transfer lock for a domain, then the status is updated to "clientTransferProhibited". To remove the status, disable the transfer lock.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.Open the Route 53 console.In the navigation pane, choose Registered domains.Select the name of the domain that you want to update.For Transfer Lock, choose Disable.Choose Save.Or, you can run the following command in the AWS CLI:aws route53domains disable-domain-transfer-lock \    --region us-east-1 \    --domain-name example.comNote: Be sure to replace the Region and domain name placeholders with your corresponding values.Related informationLocking a domain to prevent unauthorized transfer to another registrardisable-domain-transfer-lockFollow"


Question: How do I set up a Spark SQL JDBC connection on Amazon EMR?

I want to I configure a Java Database Connectivity (JDBC) driver for Spark Thrift Server so that I can run SQL queries from a SQL client on my Amazon EMR cluster.

Answer: "I want to I configure a Java Database Connectivity (JDBC) driver for Spark Thrift Server so that I can run SQL queries from a SQL client on my Amazon EMR cluster.Resolution1.    Download and install SQuirrel SQL Client.2.    Connect to the master node using SSH.3.    On the master node, run the following command to start Spark Thrift Server:sudo /usr/lib/spark/sbin/start-thriftserver.sh4.    Copy all .jar files from the /usr/lib/spark/jars directory on the master node to your local machine.5.    Open SQuirrel SQL Client and create a new driver:For Name, enter Spark JDBC Driver.For Example URL, enter jdbc:hive2://localhost:10001.6.    On the Extra Class Path tab, choose Add.7.    In the dialog box, navigate to the directory where you copied the .jar files in step 4, and then select all the files.8.    In the Class Name field, enter org.apache.hive.jdbc.HiveDriver, and then choose OK.9.    On your local machine, set up an SSH tunnel using local port forwarding:ssh -o ServerAliveInterval=10 -i path-to-key-file -N -L 10001:localhost:10001 hadoop@master-public-dns-name10.    To connect to the Spark Thrift Server, create a new alias in SQuirrel SQL Client:For Name, enter Spark JDBC.For Driver, enter Spark JDBC Driver.For URL, enter jdbc:hive2://localhost:10001.For Username, enter hadoop.11.    Run queries from SQuirrel SQL Client.Follow"


Question: I'm trying to upload a large file to Amazon S3 with encryption using an AWS KMS key. Why is the upload failing?

"I'm trying to upload a large file to my Amazon Simple Storage Service (Amazon S3) bucket. In my upload request, I'm including encryption information using an AWS Key Management Service (AWS KMS) key. However, I get an Access Denied error. Meanwhile, when I upload a smaller file with encryption information, the upload succeeds. How can I fix this?"

Answer: "I'm trying to upload a large file to my Amazon Simple Storage Service (Amazon S3) bucket. In my upload request, I'm including encryption information using an AWS Key Management Service (AWS KMS) key. However, I get an Access Denied error. Meanwhile, when I upload a smaller file with encryption information, the upload succeeds. How can I fix this?Short descriptionConfirm that you have the permission to perform kms:Decrypt actions on the AWS KMS key that you're using to encrypt the object.The AWS CLI (aws s3 commands), AWS SDKs, and many third-party programs automatically perform a multipart upload when the file is large. To perform a multipart upload with encryption using an AWS KMS key, the requester must have kms:GenerateDataKey and kms:Decrypt permissions. The kms:GenerateDataKey permissions allow the requester to initiate the upload. With kms:Decrypt permissions, newly uploaded parts can be encrypted with the same key used for previous parts of the same object.Note: After all the parts are uploaded successfully, the uploaded parts must be assembled to complete the multipart upload operation. Because the uploaded parts are server-side encrypted using a KMS key, object parts must be decrypted before they can be assembled. For this reason, the requester must have kms:Decrypt permissions for multipart upload requests using server-side encryption with KMS CMKs (SSE-KMS).ResolutionIf your AWS Identity and Access Management (IAM) role and key are in the same account, then kms:Decrypt permissions must be specified in the key policy. If your IAM role belongs to a different account than the key, kms:Decrypt permissions must be specified in both the key and IAM policy.Key policyReview the AWS KMS key policy by using the AWS Management Console policy view.In the key policy, search for statements where the Amazon Resource Name (ARN) of your IAM user or role is listed as an AWS principal. The ARN is in the format: arn:aws:iam::111122223333:user/john.Then, check the list of actions allowed by the statements associated with your IAM user or role. The list of allowed actions must include kms:Decrypt, using an SSE-KMS, for multipart uploads to work.For example, this statement in a key policy allows the user John to perform the kms:Decrypt and kms:GenerateDataKey actions:{            "Sid": "Allow use of the key",            "Effect": "Allow",            "Principal": {                "AWS": "arn:aws:iam::111122223333:user/john"            },            "Action": [                "kms:Decrypt",                "kms:GenerateDataKey"            ],            "Resource": "*"        },IAM permissionsTo review your IAM permissions, open the IAM console, and then open your IAM user or role.Review the list of permissions policies applied to your IAM user or role. Make sure that there's an applied policy that allows you to perform the kms:Decrypt action on the key used to encrypt the object.For example:{  "Version": "2012-10-17",  "Statement": {    "Effect": "Allow",    "Action": [      "kms:Decrypt",      "kms:GenerateDataKey"    ],    "Resource": [      "arn:aws:kms:example-region-1:123456789098:key/111aa2bb-333c-4d44-5555-a111bb2c33dd"    ]  }}This example statement grants the IAM user access to perform kms:Decrypt and kms:GenerateDataKey on the key (arn:aws:kms:example-region-1:123456789098:key/111aa2bb-333c-4d44-5555-a111bb2c33dd).For instructions on how to update your IAM permissions, see Changing permissions for an IAM user.Related informationAWS Policy GeneratorFollow"


Question: Why am I getting an Access Denied error for ListObjectsV2 when I run the sync command on my Amazon S3 bucket?

"I'm running the aws s3 sync command to copy objects to or from an Amazon Simple Storage Service (Amazon S3) bucket. However, I'm getting an Access Denied error when I call the ListObjectsV2 operation. How do I resolve this?"

Answer: "I'm running the aws s3 sync command to copy objects to or from an Amazon Simple Storage Service (Amazon S3) bucket. However, I'm getting an Access Denied error when I call the ListObjectsV2 operation. How do I resolve this?Short descriptionWhen you run the aws s3 sync command, Amazon S3 issues the following API calls: ListObjectsV2, CopyObject, GetObject, and PutObject.More specifically, the following happens:1. Amazon S3 lists the source and destination to check whether the object exists.2. Amazon S3 then performs the following API calls:CopyObject call for a bucket to bucket operationGetObject for a bucket to local operationPutObject for a local to bucket operationNote: This resolution assumes that the GetObject and PutObject calls are already granted to the AWS Identity Access Management (IAM) user or role. This resolution addresses how to resolve the Access Denied error caused by improper ListBucket permissions or using incorrect sync command syntax with Requester Pays.ResolutionConfiguring the IAM policyVerify that you have the permission for s3:ListBucket on the Amazon S3 buckets that you're copying objects to or from. You must have this permission to perform ListObjectsV2 actions.Note: s3:ListBucket is the name of the permission that allows a user to list the objects in a bucket. ListObjectsV2 is the name of the API call that lists the objects in a bucket.If your IAM user or role belong to another AWS account, then check whether your IAM and bucket policies permit the s3:ListBucket action. You must have permission to s3:ListBucket on both your IAM policy and bucket policy.If your user or role belongs to the bucket owner's account, then you don't need both the IAM and bucket policies to allow s3:ListBucket. You need only one of them to allow the action.Important: If either the IAM policy or bucket policy already allow the s3:ListBucket action, then check the other policy for statements that explicitly deny the action. An explicit deny statement overrides an allow statement.The following is an example IAM policy that grants access to s3:ListBucket:{  "Version": "2012-10-17",  "Statement": [{    "Sid": "Stmt1546506260896",    "Action": "s3:ListBucket",    "Effect": "Allow",    "Resource": "arn:aws:s3:::AWSDOC-EXAMPLE-BUCKET"  }]}The following is an example bucket policy that grants the user arn:aws:iam::123456789012:user/testuser access to s3:ListBucket:{  "Id": "Policy1546414473940",  "Version": "2012-10-17",  "Statement": [{    "Sid": "Stmt1546414471931",    "Action": "s3:ListBucket",    "Effect": "Allow",    "Resource": "arn:aws:s3:::AWSDOC-EXAMPLE-BUCKET",    "Principal": {      "AWS": [        "arn:aws:iam::123456789012:user/testuser"      ]    }  }]}Using the sync command with Requester PaysIf your bucket belongs to another AWS account and has Requester Pays enabled, verify that your bucket policy and IAM permissions both grant ListObjectsV2 permissions. If the ListObjectsV2 permissions are properly granted, then check your sync command syntax. When using the sync command, you must include the --request-payer requester option. Otherwise, you receive an Access Denied error.For example:aws s3 sync ./ s3://requester-pays-bucket/ --request-payer requesterRelated informationBucket owner granting cross-account bucket permissionsBucket policies and user policiesFollow"


Question: Why is OpenSearch Dashboards in red status on my Amazon OpenSearch Service domain?

OpenSearch Dashboards keeps showing red status on my Amazon OpenSearch Service domain. Why is this happening and how do I troubleshoot this?

Answer: "OpenSearch Dashboards keeps showing red status on my Amazon OpenSearch Service domain. Why is this happening and how do I troubleshoot this?Short descriptionOpenSearch Dashboards shows a green status when all health checks pass on every node of the OpenSearch Service cluster. If a health check fails, then OpenSearch Dashboards enters red status. OpenSearch Dashboards also shows red status when OpenSearch Service is in red cluster status. The OpenSearch Dashboards status can turn red for the following reasons:Node failure caused by an issue with an Amazon Elastic Compute Cloud (Amazon EC2) instance or Amazon Elastic Block Store (Amazon EBS) volume. For more information about node crashes, see Why did my OpenSearch Service node crash?Insufficient memory for your nodes.Upgrading OpenSearch Service to a newer version.Incompatibility between OpenSearch Dashboards and OpenSearch Service versions.A single-node cluster is running with a heavy load and no dedicated leader nodes. The dedicated leader node could also be unreachable. For more information about how OpenSearch Service increases cluster stability, see Dedicated leader nodes.ResolutionUse one or more of the following methods to resolve the OpenSearch Dashboards red status for your OpenSearch Service domain.Note: If your cluster shows a circuit breaker exception, first increase the circuit breaker limit. If you don't have a circuit breaker exception, try the other methods before you increase the circuit breaker limit.Tune queriesIf you're running complex queries (such as heavy aggregations), then tune the queries for maximum performance. Sudden spikes in heap memory consumption can be caused by the field data or data structures that are used for aggregation queries.Review the following API calls to identify the cause of the spike, replacing os-endpoint with your domain endpoint:$curl os-endpoint/_nodes/stats/breaker?pretty$curl "os-endpoint/_nodes/stats/indices/fielddata?level=indices&fields=*"For more information about managing memory usage, see Tune for search speed on the Elasticsearch website.Use dedicated leader nodesIt's a best practice to allocate three dedicated leader nodes for each OpenSearch Service domain. For more information about improving cluster stability, see Get started with OpenSearch Service: Use dedicated leader instances to improve cluster stability.Scale upTo scale up your domain, increase the number of nodes or choose an Amazon EC2 instance type that holds more memory. For more information about scaling, see How can I scale up or scale out my OpenSearch Service domain?Check your shard distributionCheck the index that your shards are ingesting into to confirm that they are evenly distributed across all data nodes. If your shards are unevenly distributed, one or more of the data nodes could run out of storage space.Use the following formula to confirm that the shards are distributed evenly:Total number of shards = shards per node * number of data nodesFor example, if there are 24 shards in the index, and there are eight data nodes, then you have three shards per node. For more information about the number of shards needed, see Get started with OpenSearch Service: How many shards do I need?Check your versionsImportant: Your OpenSearch Dashboards and OpenSearch Service versions must be compatible.Run the following API call to confirm that your versions are compatible, replacing os-endpoint with your domain endpoint:$curl os-endpoint/.kibana/config/_search?prettyNote: An unsuccessful command can indicate compatibility issues between OpenSearch Dashboards and Supported OpenSearch Service versions. For more information about compatible OpenSearch Dashboards and Elasticsearch versions, see Set up on the Elasticsearch website.Monitor resourcesSet up Amazon CloudWatch alarms that notify you when resources are used above a certain threshold. For example, if you set an alarm for JVM memory pressure, then take action before the pressure reaches 100%. For more information about CloudWatch alarms, see Recommended CloudWatch alarms and Improve the operational efficiency of OpenSearch Service domains with automated alarms using CloudWatch.Increase the circuit breaker limitTo prevent the cluster from running out of memory, try increasing the parent or field data circuit breaker limit. For more information about field data circuit breaker limits, see Circuit breaker settings on the Elasticsearch website.Related informationCan't access OpenSearch DashboardsHow do I resolve the "Courier fetch: n of m shards failed" error in OpenSearch Dashboards on Amazon OpenSearch Service?How do I resolve the "cannot restore index [.kibana] because it's open" error in Amazon OpenSearch Service?Troubleshooting an upgradeFollow"


Question: How do I troubleshoot connectivity issues between my Amazon ECS tasks for an Amazon EC2 launch type and an Amazon RDS database?

My application is running as a set of tasks launched by Amazon Elastic Container Service (Amazon ECS) on Amazon Elastic Compute Cloud (Amazon EC2) instances. My application can't communicate with the Amazon Relational Database Service (Amazon RDS) database.

Answer: "My application is running as a set of tasks launched by Amazon Elastic Container Service (Amazon ECS) on Amazon Elastic Compute Cloud (Amazon EC2) instances. My application can't communicate with the Amazon Relational Database Service (Amazon RDS) database.ResolutionVerify your network configurationsTo verify if a container instance can establish a connection to the database, complete the following steps for either Linux-based or Windows-based container instances:For Linux-based container instances:1.    Use SSH to connect to the container instance where your task is placed.2.    To connect to your RDS database, run the following command:$ telnet test.ab12cde3fg4.us-east-1.rds.amazonaws.com 3306Note: Replace test.ab12cde3fg4.us-east-1.rds.amazonaws.com with your database endpoint. Replace 3306 with your database port.The output looks similar to the following:> Trying 172.31.122.28 > Connected to test.ab12cde3fg4.us-east-1.rds.amazonaws.com > Escape character is '^]'.Important: Telnet isn't pre-installed on Amazon ECS-optimized Amazon Machine Images (AMIs). To install Telnet, run the sudo yum install telnet -y command.For Windows-based container instances:1.    Use the Remote Desktop Protocol (RDP) to connect to the container instance where your task is placed.2.    To connect to your RDS database, run the following command using either the Windows command prompt or Windows PowerShell:$ telnet test.ab12cde3fg4.us-east-1.rds.amazonaws.com 3306Note: Replace test.ab12cde3fg4.us-east-1.rds.amazonaws.com with your database endpoint. Replace 3306 with your database port.Important: Telnet isn't pre-installed on Amazon ECS-optimized Windows AMIs. To install Telnet, run the Install-WindowsFeature -Name Telnet-Client command using PowerShell as administrator.If the connection is established, a blank page appears.If the connection isn't established and you receive "Connection Timed Out" or "Connect failed' errors, then complete the following steps:1.    Check if the attached security groups allow access to the RDS database. You can use either the DescribeInstances API call, or the Description tab for your selected instance ID in the Amazon EC2 console.Note: In the bridge and host networking mode, security groups attached to the container instance govern access to the database. In the awsvpc network mode, the security groups associated during the launch of the service or task govern access.Tip: As a best practice, create a security group that allows incoming traffic from the database port. Then, attach the security group to the database and container instance, or associate the security group with tasks based on awsvpc.2.    Check if the network access control list (network ACL) and route table associated with the subnet allow access to the database.Verify the database connection parameters1.    In the environment section of your container definition, pass your environment variables securely. To pass them securely, reference your environment variables from AWS Systems Manager Parameter Store or AWS Secrets Manager.Note: An application uses parameters (such as database endpoint, database port, and database access credentials) to establish a connection with the database. These parameters are usually passed as environment variables to the task.2.    If the container in your task can establish a connection with the database, but can't authenticate due to incorrect connection parameters (such as database user name or database password), then reset your database password.3.    Remove any leading or trailing character spaces from your connection parameters.Note: Syntax errors can result in a failed connection between your container and the RDS database.Follow"