VishaalY/solutions-architect-hf-dataset huggingface dataset:
Question: How can I troubleshoot Lambda function invoke issues with Amazon EFS integration?

I invoked an AWS Lambda function with Amazon Elastic File System (Amazon EFS) integration and received an error message.

Short descriptionThe following are pre-requisites for mounting Amazon EFS access points with Lambda:The Lambda function's execution role must have the following elasticfilesystem permissions:elasticfilesystem:ClientMountelasticfilesystem:ClientWrite (not required for read-only connections)Your AWS Identify and Access Management (IAM) user must have the following permissions:elasticfilesystem:DescribeMountTargetsThe EFS File System security group must allow NFS (port 2049) inbound traffic from the Lambda security group or IP address range.The Lambda security group must allow NFS (port 2049) outbound traffic to the EFS security group or IP address range.The Lambda function and Amazon EFS access points must be in the same AWS Region and Availability Zone.For more information, see How do I create the correct EFS access point configuration to mount my file system using a Lambda function?ResolutionFollow these troubleshooting steps for the error message with your Lambda function.EFSMountFailureException:The Lambda function couldn't mount the configured EFS file system due to a permission or configuration issue. Check the Lambda functions permissions. Then, confirm that the EFS file system and access point exist and are ready for use. For more information, see Function could not mount the EFS file system.EFSMountConnectivityException:The Lambda function couldn't make a network connection to the configured EFS file system with the NFS protocol (TCP port 2049). Check the security group and routing configuration for the Amazon Virtual Private Cloud (Amazon VPC) subnets. For more information, see Function could not connect to the EFS file system.EFSMountTimeoutException:The Lambda function was able to make a network connection to the configured EFS file system, but the mount operation timed out. Retry invoking the Lambda function. If the Lambda function times out again, then limit the functions reserved concurrency to reduce the load volume on the EFS file system. For more information, see Function could not mount the EFS file system due to timeout.PermissionError: Permission denied: '/mnt/xyz/abc':Lambda doesn't have access to the specified Amazon EFS access point. To troubleshoot Amazon EFS access points, see What are common EFS access point configurations?For more information, see Troubleshoot invocation issues in Lambda.

Related informationWorking with Amazon EFS access points
Question: How can I see who's been accessing my Amazon S3 buckets and objects?

I'm looking for a way to track who's accessing my Amazon Simple Storage Service (Amazon S3) buckets and objects. How can I do that?ResolutionYou can track who's accessing your bucket and objects in the following ways:Use Amazon S3 server access logging to see information about requests to your buckets and objects. You can use Amazon Athena to analyze your server access logs.Use AWS CloudTrail to track API calls to your Amazon S3 resources. You can also use Athena to query your CloudTrail logs.

Related informationMonitoring Amazon S3
Question: How do I restore the backup of my Amazon DynamoDB table to a different Region?

I want to restore the backup of my Amazon DynamoDB table to a different Region.

ResolutionTo restore your DynamoDB table to a different Region, you can use either of the following approaches.Restore a DynamoDB table to a different Region using DynamoDBOpen the DynamoDB console.In the navigation pane, choose Backups.In the list displayed, choose the backup from which you want to restore the table.Choose Restore.For Name of restored table, enter the new table name.For Secondary indexes, select your desired option.For Destination AWS Region, select Cross-Region.For Select the destination AWS Region, choose the Region of your choice.For Encryption key management, select your desired option.Choose Restore.Restore a DynamoDB table to a different Region using AWS GlueYou can use an AWS Glue job to restore a DynamoDB table to another Region. AWS Glue provides more flexibility with the restoration process. You might choose this approach if you don't want to restore all attributes or fields to the target table in the new Region. This approach works only for a table that's exported to Amazon Simple Storage Service (Amazon S3).1.    After exporting the DynamoDB table to Amazon S3 using the Export to S3 feature, create an AWS Glue job. Be sure to specify the following information in the Script tab:datasource0 = glueContext.create_dynamic_frame.from_options(    connection_type="dynamodb",    connection_options={        "dynamodb.export": "ddb",        "dynamodb.tableArn": "arn:aws:dynamodb:source-region:account-number:table/TableName",        "dynamodb.unnestDDBJson": True,        "dynamodb.s3.bucket": "example-bucket",        "dynamodb.s3.prefix": "dynamodb",        "dynamodb.s3.bucketOwner": "account-number",    })Note: Be sure to use the transform node ApplyMapping, and specify the fields that must be present in the target table. This setting automatically generates the PySpark code based on the input provided.Example:applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [("resource_id", "string", "resource_id", "string")], transformation_ctx = "applymapping1")2.    Specify a sink operation to directly write to the destination table in the target Region.Example:glueContext.write_dynamic_frame_from_options (frame = MappedFrame, connection_type = "dynamodb", connection_options = { "dynamodb.region": "example-region", "dynamodb.output.tableName": "example_table", "dynamodb.throughput.write.percent": "1.0" })3.    Run the job from the AWS Glue console to load data from the current Region to the target Region.

Related informationRestoring a DynamoDB table from a backupPoint-in-time recovery for DynamoDBWorking with jobs on the AWS Glue console
Question: Why does failover take longer than expected on my AWS Direct Connect connection after configuring BFD?

I enabled Bidirectional Forwarding Detection (BFD) for my AWS Direct Connect connection for fast failure detection and failover with graceful restart enabled. However, I have failover delays or connection issues.

ResolutionIt's a best practice not to configure graceful restart and BFD at the same time to avoid failover or connection issues. For fast failover, configure BFD without graceful restart enabled.For more information, see BGP quotas.

Related informationDirect Connect network requirements
Question: How do I troubleshoot Amazon Pinpoint campaign message failures?

My Amazon Pinpoint campaign isn't processing or targeting any endpoints, and it isn't sending any messages. How do I troubleshoot campaign failures in Amazon Pinpoint?ResolutionFor endpoints that aren't processed or targeted1.    Verify if the campaign has the Use recipients local time setting activated. For instructions, see Sending the campaign at a specific date and time in the Amazon Pinpoint User Guide.2.    If the setting is activated, then make sure that each endpoint definition includes a valid Demographic.Timezone attribute.Note: If an endpoint doesn't have a valid Demographic.Timezone attribute defined and the campaign's Use recipients local time setting is activated, the endpoint isn't processed.For endpoints that are processed and targeted, but not receiving messagesAmazon Pinpoint campaigns can fail to deliver messages to specific endpoints for many reasons. To troubleshoot message failures to specific endpoints, first configure Amazon Pinpoint to send information about events to Amazon Kinesis. Then, recreate the message failures and review the failed events in Amazon Kinesis to identify what's causing the error. After you've identified what's causing the error, remediate the issue.Note: The event_type value in each streaming event indicates the cause of most message failures. If the event_type value doesn't provide a clear indication of what's causing the message failure, then review your campaign's CampaignSendMessageThrottled metric in Amazon CloudWatch. This metric shows the number of campaign messages that weren't sent because your AWS account's ability to send messages was throttled. For more information, see Amazon Pinpoint quotas.For failed emailsMake sure that you identify any streaming events with the following event_type value: _email.rendering_failure. This event type usually indicates that the email template includes a variable that is either not valid or missing.-or-(If you don't have Kinesis streaming activated) Review your campaign's Amazon Simple Email Service (Amazon SES) Rendering Failures metric in Amazon CloudWatch. This metric also usually indicates that the email template includes a variable that is either not valid or missing.If you see streaming events with an _email.rendering_failure event type, or any Amazon SES Rendering Failures metrics in CloudWatch, do the following:1.    Verify that all of the message variables in the template file have a corresponding endpoint attribute in the endpoint definition (segment file).2.    Verify that all of the message variables in the template file are in the correct format in the endpoint definition.3.    Specify the Default attribute values for all of the message variables in the template file. For more information, see Creating email templates in the Amazon Pinpoint User Guide.Note: If you don't specify a default value and a value doesn't exist for a recipient, then Amazon Pinpoint doesn't send the message.For more information, see Adding personalized content to message templates in the Amazon Pinpoint User Guide.
Question: How can I identify and resolve unwanted health checks from Route 53?

My server is receiving unwanted requests from Amazon Route 53 health check servers.

Short descriptionWhen you associate health checks with an endpoint, Amazon Route 53 sends health check requests to the endpoint IP address. These health checks validate that the endpoint IP addresses are operating as intended. An issue might occur if an incorrect IP address is specified or if a health check isn't updated or deleted when necessary.

ResolutionIdentify the source of unwanted requests1.    Use Route 53 IP address ranges to find the source IP address of the unwanted request. For more information, see ROUTE53_HEALTHCHECKS in IP address ranges of Route 53 servers.2.    Check the application server logs to determine whether the Route 53 health check servers sent the request. When performing health checks, Route 53 health checks set the following HTTP header:"Amazon-Route53-Health-Check-Service (ref <reference ID/ b5996862-d894-4595-88da-7940808e9665>; report http://amzn.to/1vsZADi)"Example Application Load Balancer access log:http 2020-05-12T14:14:25.000265Z app/myapplicationloadbalancer 54.241.32.97:49816 10.0.3.64:80 -1 -1 -1 502 - 241 288 "GET http:// <ALB DNS NAME>:80/ HTTP/1.1" "Amazon-Route53-Health-Check-Service (ref b5996862-d894-4595-88da-7940808e9665; report http://amzn.to/1vsZADi)" - - arn:aws:elasticloadbalancing:us-east-1:<account ID>:targetgroup/mytargetgroupExample Microsoft Internet Information Services (IIS) access log:Amazon+Route+53+Health+Check+Service;+ref:b5996862-d894-4595-88da-7940808e9665;+report+http://amzn.to/1vsZADiExample Apache access log:54.228.16.1 - - [time] "GET / HTTP/1.1" 403 3839 "-" "Amazon Route 53 Health Check Service; ref:47d9bc51-39d6-4cd9-9a7f-4c981c5db165; report http://amzn.to/1vsZADi"Example NGINX access log:NGINX access log entry: 54.232.40.80 - - [time] "GET / HTTP/1.1" 200 3770 "-" "Amazon Route 53 Health Check Service; ref:2e44063d-3b85-47c3-801e-6748cd542386; report http://amzn.to/1vsZADi" "-"Delete or block the source of unwanted requests1.    Copy the health check ID from the application service logs.2.    If the health check is available from your AWS account, then update the health check to monitor the intended IP address or domain name. Or, if it's no longer required, then delete the health check.If the health check isn't available from your AWS account, then block the IP address of the health check. To block the IP address, use firewall rules, security groups, or network access control lists (NACLs).Important: To report suspected Route 53 health check abuse, see Stop unwanted Amazon Route 53 health checks.

Related informationHow can I stop Route 53 health check requests that are sent to my application?
Question: Why can't my Secrets Manager rotation function connect to an Aurora PostgreSQL database using scram-sha-256?

My AWS Secrets Manger rotation function can't connect to an Amazon Aurora PostgreSQL database using the scram-sha-256 algorithm.

Short descriptionIf your database is Aurora PostgreSQL version 13 or later, the rotation function might fail to connect to the database if:The database uses scram-sha-256 to encrypt passwords.The rotation function uses libpq-based client's version 9 or earlier.Important: If you set up automatic secret rotation before December 30, 2021, then your rotation function bundled an older version of libpq that doesn't support scram-sha-256.

ResolutionFollow these steps to check for database users for scram-sha-256 encryption and the rotation function libpq version.Determine which database users use scram-sha-256 encryptionTo check for users with scram-sha-256 encrypted passwords, see the AWS blog SCRAM authentication in Amazon Relational Database Service for PostgreSQL 13.Determine what version of libpq your rotation function uses1.    Open the Lambda console.2.    In the navigation pane, choose Functions, and then select the Lambda function name that failed to rotate.3.    Choose the Code tab.4.    Choose Actions, choose Export function, and then choose Download deployment package.5.    Uncompress the zip file into the work directory.6.    Run the following Linux command in the work directory:readelf -a libpq.so.5 | grep RUNPATHIf you see the string PostgreSQL-9.4.x, or any major version less than 10, then the rotation function doesn't support scram-sha-256.Example output for a rotation function that doesn't support scram-sha-256:0x000000000000001d (RUNPATH) Library runpath: [/local/p4clients/pkgbuild-a1b2c/workspace/build/PostgreSQL/PostgreSQL-9.4.x_client_only.123456.0/AL2_x86_64/DEV.STD.PTHREAD/build/private/tmp/brazil-path/build.libfarm/lib:/local/p4clients/pkgbuild-a1b2c/workspace/src/PostgreSQL/build/private/install/lib]    * Example output for a rotation function that supports scram-sha-256:Example output for a rotation function that supports scram-sha-256:0x000000000000001d (RUNPATH) Library runpath: [/local/p4clients/pkgbuild-a1b2c/workspace/build/PostgreSQL/PostgreSQL-10.x_client_only.123456.0/AL2_x86_64/DEV.STD.PTHREAD/build/private/tmp/brazil-path/build.libfarm/lib:/local/p4clients/pkgbuild-a1b2c/workspace/src/PostgreSQL/build/private/install/lib]If your database uses scram-sha-256 and the example output indicate that the rotation function doesn't support scram-sha-256, then you must recreate your rotation function.

Related informationTroubleshoot AWS Secrets Manager rotation
Question: How can I calculate my burst credit billing on my EC2 instance?

I want to calculate my burst credit billing on my Amazon Elastic Compute Cloud (Amazon EC2) instance. How can I do this?ResolutionNote: Burst credit billing applies to EC2 burstable instance types only. For example, T4g, T3a, and T3 instance types, and the previous generation T2 instance types.You can configure burstable instances to run in one of two modes: standard mode or unlimited mode.You can check whether your burstable performance instance is configured as unlimited or standard using the EC2 console or the AWS Command Line Interface (AWS CLI). For more information, see View the credit specification of a burstable performance instance and View the default credit specification.Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.Billing in standard modeIn standard mode, you're charged using the standard  On-Demand hourly rate for your instance.Billing in unlimited modeIn unlimited mode, the hourly instance price automatically covers all CPU usage spikes for the shorter of the following:The time that the instance's average CPU utilization is at or below the baseline over a rolling 24-hour period.The instance's lifetime.If the instance runs at a higher CPU utilization for a prolonged period, it can do so for a flat additional rate per vCPU-Hour. For information on vCPU-Hour charges, see T2/T3/T4g Unlimited Mode Pricing.Credits that are spent by an instance in unlimited mode after it depletes its accrued credit balance are called surplus credits. For information on when surplus credit charges occur, see Surplus credits can incur charges.You can use the Amazon CloudWatch metric CPUSurplusCreditsCharged to see surplus credits that are charged for your instance. For more information, see  Additional CloudWatch metrics for burstable performance instances.For examples of how EC2 burstable instances in unlimited mode spend credits and are charged, see Unlimited mode examples.

Related informationKey concepts and definitions for burstable performance instances
Question: How can I automatically attach a persistent secondary EBS volume to a new EC2 Linux Spot Instance at boot?

I want to use a user data script to automatically launch a persistent secondary Amazon Elastic Block Store (Amazon EBS) volume to my new Amazon Elastic Compute Cloud (Amazon EC2) Linux Spot Instance at boot. How do I do this?Short descriptionTo automatically attach a persistent secondary EBS volume to a new EC2 Linux Spot Instance at boot, add a user data script to an EC2 launch template. Use the template when configuring your Spot Instance Request.PrerequisiteCreate or use an AWS Identity and Access Management (IAM) role that at a minimum has attach-volume access granted for Amazon EC2. This role will be attached to the launch template.

ResolutionStep 1: Configure a launch template with an IAM Role and user data script1.    Open the Amazon EC2 console.2.    Select Launch Templates, and then select Create launch template.3.    Choose the instance AMI, type, and size. Or, choose an existing AMI.4.    Associate a key pair with the template.5.    Choose a subnet in the same Availability Zone as the EBS volume.6.    Select Advanced details.7.    Add the IAM role that at a minimum has attach-volume access granted, as shown in the following example:{    "Version": "2012-10-17",    "Statement": [        {            "Effect": "Allow",            "Action": [                "ec2:AttachVolume",                "ec2:DetachVolume"            ],            "Resource": [                "arn:aws:ec2:*:*:instance/*",                "arn:aws:ec2:*:*:volume/vol-xxxxxxxxxxxx"            ]        },        {            "Effect": "Allow",            "Action": "ec2:DescribeVolumes",            "Resource": "arn:aws:ec2:*:*:volume/vol-xxxxxxxxxxxx"        }    ]8.    Add a user data script to the template. The following is an example user data script. Replace the region and volume-id to match your environment.#!/bin/bash      OUTPUT=$(curl http://169.254.169.254/latest/meta-data/instance-id)      aws ec2 attach-volume --volume-id vol-xxxxxxxxxxxx --device /dev/xvdf --instance-id $OUTPUT --region ap-southeast-1Step 2: Configure a Spot Request using the launch template created in Step 11.    Select Spot Instance, and then select Request Spot Instance.2.    Select Launch Templates, and then choose the Launch Template created in Step 1. All the information configured on the template auto-populates.3.    Choose the same Availability Zone as the EBS volume.4.    Select create Spot Request.After the Spot request completes, the persistent secondary EBS volume is attached to the new Spot Instance automatically at boot.
Question: How can I share CloudHSM clusters with other AWS accounts?

My organization has multiple AWS accounts. How can I share my AWS CloudHSM clusters with these AWS accounts?Short descriptionYou can use AWS Resource Access Manager to share subnets for the Amazon Virtual Private Cloud (Amazon VPC) containing your CloudHSM with other AWS accounts.

ResolutionUse AWS RAM to access CloudHSM with another AWS account in AWS Organizations. In the following example, Account 1 contains the CloudHSM cluster, and Account 2 contains the CloudHSM client instance.Use AWS RAM to enable sharingWith your Organizations management account, open the AWS RAM console in the same Region as your CloudHSM, and choose Settings.Select the Enable sharing within your AWS Organization check box.With your Organizations management account, open the AWS Organization Console.Choose Settings, and note the Organization ID.Create a resource share with Account 1 for with other accountsOpen the AWS RAM console with Account 1 in the same Region as your CloudHSM.In the navigation pane, in Shared by me, choose Resource shares.Choose Create resource share.In Name, enter a name for the resource share.In Resources, choose the Amazon VPC subnet ID for your CloudHSM.In Principals, uncheck select Allow external accounts.In the Add AWS account number search pane, enter the Organization ID, choose Add, and then choose Create resource share.Note: You can also share Organizational Units (OUs) and AWS accounts.Configure the security group to allow the CloudHSM client to connect to the CloudHSM clusterOpen the CloudHSM console with Account 1 in the same Region as your CloudHSM cluster.In the navigation pane, choose Clusters.In Cluster ID, choose the CloudHSM cluster that you want to share.In Security group, choose the security group.Choose the Inbound tab, and then choose Edit.Choose Add Rule.In Port Range, enter 2223-2225.In Source, enter the private IP address of your client instance, and then choose Save.Note: To get the client instance private IP address, see view the IPv4 addresses using the EC2 console.Create client instances for the subnets shared with Account 2Open the Amazon EC2 console with Account 2, choose Launch Instance, and then select an Amazon Machine Image (AMI).Choose Next: Configure Instance Details.In Network, choose the Amazon VPC that's shared with Account 2.In Subnet, choose the subnet that's shared with Account 2.In Auto-assign Public IP, choose Enable, and then choose Next: Add Storage.Choose Next: Add Tags, and then choose Next: Configure Security Group.In Assign a security group, choose either Create a new security group or Select an existing security group (depending on your instance type).Choose Review and Launch, and then choose Launch.Choose an existing key pair or create a new one (depending on your instance type), and then select the agreement check box.Choose Launch Instances.

Related informationSharing your AWS resourcesWorking with security groupsShared subnets permissions