Question: How can I use Data Pipeline to back up a DynamoDB table to an S3 bucket that's in a different account?

I want to use AWS Data Pipeline to back up an Amazon DynamoDB table to an Amazon Simple Storage Service (Amazon S3) bucket that's in a different AWS account.

Answer: "I want to use AWS Data Pipeline to back up an Amazon DynamoDB table to an Amazon Simple Storage Service (Amazon S3) bucket that's in a different AWS account.Short descriptionNote: The source account is the account where the DynamoDB table exists. The destination account is the account where the Amazon S3 bucket exists.In the source account, attach an AWS Identity and Access Management (IAM) policy that grants Amazon S3 permissions to the DataPipeline service role and DataPipeline resource role.In the destination account, create a bucket policy that allows the DataPipeline service role and DataPipeline resource role in the source account to access the S3 bucket.In the source account, create a pipeline using the Export DynamoDB table to S3 Data Pipeline template.Add the BucketOwnerFullControl or AuthenticatedRead canned access control list (ACL) to the Step field of the pipeline's EmrActivity object.Activate the pipeline to back up the DynamoDB table to the S3 bucket in the destination account.Create a DynamoDB table in the destination account.To restore the source table to the destination table, create a pipeline using the Import DynamoDB backup data from S3 Data Pipeline template.ResolutionAttach an IAM policy to the Data Pipeline default roles1.    In the source account, open the IAM console.2.    Choose Policies, and then choose Create policy.3.    Choose the JSON tab, and then enter an IAM policy similar to the following. Replace awsdoc-example-bucket with the name of the S3 bucket in the destination account.{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "",      "Effect": "Allow",      "Action": [        "s3:AbortMultipartUpload",        "s3:GetBucketLocation",        "s3:GetObject",        "s3:ListBucket",        "s3:ListBucketMultipartUploads",        "s3:PutObject"      ],      "Resource": [        "arn:aws:s3:::awsdoc-example-bucket/*",        "arn:aws:s3:::awsdoc-example-bucket"      ]    }  ]}4.    Choose Review policy.5.    Enter a Name for the policy, and then choose Create policy.6.    In the list of policies, select the check box next to the name of the policy that you just created. You can use the Filter menu and the search box to filter the list of policies.7.    Choose Policy actions, and then choose Attach.8.    Select the DataPipeline service role and DataPipeline resource role, and then choose Attach policy.Add a bucket policy to the S3 bucketIn the destination account, create a bucket policy similar to the following. Replace these values in the following example:111122223333: the ID of the Data Pipeline account. For more information, see Finding your AWS account ID.awsdoc-example-bucket: the name of the S3 bucket{  "Version": "2012-10-17",  "Id": "",  "Statement": [    {      "Sid": "",      "Effect": "Allow",      "Action": "s3:*",      "Principal": {        "AWS": [          "arn:aws:iam::111122223333:role/DataPipelineDefaultRole",          "arn:aws:iam::111122223333:role/DataPipelineDefaultResourceRole"        ]      },      "Resource": [        "arn:aws:s3:::awsdoc-example-bucket",        "arn:aws:s3:::awsdoc-example-bucket/*"      ]    }  ]}Create and activate the pipeline1.    In the source account, create a pipeline using the Export DynamoDB table to S3 Data Pipeline template:In the Parameters section, enter the Source DynamoDB table name and the Output S3 folder. Use the format s3://awsdoc-example-bucket/ for the bucket.In the Security/Access section, for IAM roles, choose Default.2.    Before you Activate the pipeline, choose Edit in Architect.3.    Open the Activities section, and then find the EmrActivity object.4.    In the Step field, add the BucketOwnerFullControl or AuthenticatedRead canned access control list (ACL). These canned ACLs give the Amazon EMR Apache Hadoop job permissions to write to the S3 bucket in the destination account. Be sure to use the format -Dfs.s3.canned.acl=BucketOwnerFullControl. Put the statement between org.apache.hadoop.dynamodb.tools.DynamoDbExport and #{output.directoryPath}. Example:s3://dynamodb-dpl-#{myDDBRegion}/emr-ddb-storage-handler/4.11.0/emr-dynamodb-tools-4.11.0-SNAPSHOT-jar-with-dependencies.jar,org.apache.hadoop.dynamodb.tools.DynamoDBExport,-Dfs.s3.canned.acl=BucketOwnerFullControl,#{output.directoryPath},#{input.tableName},#{input.readThroughputPercent}5.    Choose Save, and then choose Activate to activate the pipeline and back up the DynamoDB table to the S3 bucket in the destination account.(Optional) Restore the backup in the destination accountIn the destination account, create a DynamoDB table. The table doesn't have to be empty. However, the import process replaces items that have the same keys as the items in the export file.Create a pipeline using the Import DynamoDB backup data from S3 Data Pipeline template:In the Parameters section, for Input S3 folder, enter the S3 bucket where the DynamoDB backup is stored.In the Security/Access section, for IAM roles, choose Default.Activate the pipeline to restore the backup to the destination table.Related informationBucket owner granting cross-account bucket permissionsManaging IAM policiesFollow"


Question: How do I see a list of my Amazon EC2 instances that are connected to Amazon EFS?

I want to see a list of my Amazon Elastic Compute Cloud (Amazon EC2) instances that have mounted an Amazon Elastic File System (Amazon EFS). How do I do that?

Answer: "I want to see a list of my Amazon Elastic Compute Cloud (Amazon EC2) instances that have mounted an Amazon Elastic File System (Amazon EFS). How do I do that?Short descriptionThe VPC flow logs are used to track the traffic on the elastic network interface of each Amazon EFS mount target. The flow logs can be pushed to Amazon CloudWatch logs. Using CloudWatch logs insights, the traffic flow on the mount target's elastic network interface is filtered to provide the list of Amazon EC2 instances that have mounted an Amazon EFS in a specific timestamp.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.Perform the following steps once. After completing these steps, each time you want to list the IP addresses of the clients mounting the Amazon EFS, run a query to create a current list.Create a log groupOpen the CloudWatch console.In the navigation pane, choose Logs, and then choose Log groups.Choose Create log group.Enter a Log group name, Retention setting and an optional KMS key ARN. You can also add Tags here.Choose Create.Create an Identity and Access Management (IAM) role with permission for publishing flow logs to CloudWatch LogsOpen the IAM console.In the navigation pane, under Access management, choose Roles.Choose Create role and create a new IAM role.The IAM policy that's attached to your IAM role must include the permissions to publish the VPC flow logs to CloudWatch. Similarly, it must have a trust relationship that allows the flow logs service to assume the role.Get the list of elastic network interfaces used by the mount target of your Amazon EFSNote: Amazon EFS has a different mount target for each Availability Zone.Open the Amazon EFS console.Under File systems, choose the specific Amazon EFS, and then choose View details.Click on Network, and note the Network Interface ID for each mount target.Create the flow logsOpen the Amazon EC2 console.Choose Network & Security, and then choose Network Interfaces.Choose all the elastic network interfaces that are being used by the mount target.From the Actions menu, choose Create flow log. Use the following values when creating the flow log:Name: OptionalFilter: Select AllMaximum aggregation interval: Choose from default 10 mins or 1 minDestination: Select Send to CloudWatch logsDestination log group: Choose the log group you createdIAM role: Choose the IAM Role you createdLog record format: Chose from AWS default format or Custom format.Tag: OptionalChoose Create.Monitor the flow log status by choosing the specific elastic network interface that you created a flow log for. At the bottom of the screen, choose Flow logs. Verify that the Status is Active.The first flow log are pushed to CloudWatch Logs after about 10 minutes.Verify that the flow logs are in CloudWatch LogsOpen the CloudWatch console, and then choose Logs.Choose the Log groups created in step 1.Verify that all the log streams you created now appear. Each elastic network interface has a different log stream.Run a queryTo run a query in CloudWatch Logs Insights:In the CloudWatch console, choose Logs, and then choose Logs Insights.Choose the log groups that you created from the drop-down menu.Choose the duration that you want to review the flow logs for (5m, 30m, 1h, 3h, 12, or Custom).Enter the query below:fields @timestamp, @message | filter dstPort="2049" | stats count(*) as FlowLogEntries by srcAddr | sort FlowLogEntries descNote: This query reviews all flow logs generated for all mount targets. It filters the logs that have a destination port set to Port=2049 (Amazon EFS clients connect to mount targets on NFS port 2049). It retrieves all unique source IPs (Amazon EFS client IPs), and sorts them by the most active client connections. Activity is determined by the number of entries in the flow log.Choose Run query. The output contains the list of private IPs of all the Amazon EC2 instances where you mounted Amazon EFS.The following is an example of the query output:#          srcAddr              FlowLogEntries1      111.22.33.44                 782      111.55.66.77                363      111.88.99.000                33Run a query using the AWS CLI <br>To run a query from the AWS CLI, follow these steps:After the VPC flow log is set up, you can use an AWS CLI command to run the query.Check that the AWS CLI is updated to the latest version:$ pip install --upgrade awscliCheck that jq is installed:yum install -y jqUse the following AWS CLI query using these query parameters:log-group-name: Enter the log group name you created.start-time / end-time: These values are in Unix/Epoch time. Use the epoch converter to convert human-readable timestamps to Unix/Epoch time.test.json: You can optionally change the json file name each time you run this command. Changing the name makes sure that the previous output isn't merged with the new output.sleep: This value (in seconds) is used as a delay while the CloudWatch Logs insights query is carried out. The value entered depends on how long you want to review the flow logs. If you want to review the logs for a longer duration, such as weeks, then increase the sleep time.aws logs start-query --log-group-name EFS-ENI-Flowlogs --start-time 1643127618 --end-time 1643128901 --query-string 'filter dstPort="2049" | stats count(*) as FlowLogEntries by srcAddr | sort FlowLogEntries desc' > test.json && sleep 10 && jq .queryId test.json | xargs aws logs get-query-results --query-idFollow"


Question: "How do I turn on functions, procedures, and triggers for my Amazon RDS for MySQL DB instance?"

"I want to turn on functions, procedures, and triggers for my Amazon Relational Database Service (Amazon RDS) for MySQL DB instance."

Answer: "I want to turn on functions, procedures, and triggers for my Amazon Relational Database Service (Amazon RDS) for MySQL DB instance.ResolutionAmazon RDS is a managed service and doesn't provide system access (SUPER privileges). If you turn on binary logging, then set log_bin_trust_function_creators to true in the custom database (DB) parameter group for your DB instance.If you create a DB instance without specifying a DB parameter group, then Amazon RDS creates a new default DB parameter group. For more information, see Working with parameter groups.Create a DB parameter group.Modify the custom DB parameter group, and then set the parameter: log_bin_trust_function_creators=1Choose Save Changes.Note: Before using the DB parameter group with a DB instance, wait at least 5 minutes.In the navigation pane, choose Databases.Choose the DB instance that you want to associate with the DB parameter group.Choose Modify.Select the parameter group that you want to associate with the DB instance.Reboot the DB instance.Note: The parameter group name changes immediately, but parameter group changes aren't applied until you reboot the instance without failover.If you're already using a custom parameter group, then complete only steps 2–3. The parameter log_bin_trust_function_creators is a dynamic parameter that doesn't require a DB reboot.When you turn on automated backup for a MySQL DB instance, you also turn on binary logging. When creating a trigger, you might receive the following error message:"ERROR 1419 (HY000): You don't have the SUPER privilege and binary logging is enabled (you might want to use the less safe log_bin_trust_function_creators variable)"If you receive this error, then modify the log_bin_trust_function_creators parameter to 1. This allows functions, procedures, and triggers on your DB instance.Note: When you set log_bin_trust_function_creators=1, unsafe events might be written to the binary log. Binary logging is statement based (binlog_format=STATEMENT).For more details about the parameter log_bin_trust_function_creators, see log_bin_trust_function_creators and Stored program binary logging in the MySQL documentation.Related informationHow can I resolve 1227 and definer errors when importing data to my Amazon RDS for MySQL DB instance using mysqldump?Modifying parameters in a DB cluster parameter groupFollow"


Question: How do I mount an Amazon EFS file system on an Amazon ECS container or task running on Fargate?

I want to mount an Amazon Elastic File System (Amazon EFS) file system on an Amazon Elastic Container Service (Amazon ECS) container or task running on AWS Fargate.

Answer: "I want to mount an Amazon Elastic File System (Amazon EFS) file system on an Amazon Elastic Container Service (Amazon ECS) container or task running on AWS Fargate.Short descriptionTo mount an Amazon EFS file system on a Fargate task or container, you must first create a task definition. Then, make that task definition available to the containers in your task across all Availability Zones in your AWS Region. Then, your Fargate tasks use Amazon EFS to automatically mount the file system to the tasks that you specify in your task definition.Important: The following resolution applies to the Fargate platform version 1.4.0 or later, which has persistent storage that you can define at the task and container level in Amazon ECS. Fargate platform versions 1.3.0 or earlier don't support persistent storage using Amazon EFS.Before you complete the steps in the Resolution section, you must have the following:Amazon ECS clusterAmazon Virtual Private Cloud (Amazon VPC)Amazon EFS file systemResolutionCreate and configure an Amazon EFS file system1.    Create an Amazon EFS file system, and then note the EFS ID and security group ID.Note: Your Amazon EFS file system, Amazon ECS cluster, and Fargate tasks must all be in the same VPC.2.    To allow inbound connections on port 2049 (Network File System, or NFS) from the security group associated with your Fargate task or service, edit the security group rules of your EFS file system.3.    Update the security group of your Amazon ECS service to allow outbound connections on port 2049 to your Amazon EFS file system's security group.Create a task definition1.    Open the Amazon ECS console.2.    From the navigation pane, choose Task Definitions, and then choose Create new Task Definition.3.    In the Select launch type compatibility section, choose FARGATE, and choose Next Step.4.    In the Configure task and container definitions section, for Task Definition Name, enter a name for your task definition.5.    In the Volumes section, choose Add volume.6.    For Name, enter a name for your volume.7.    For Volume type, enter EFS.8.    For File system ID, enter the ID for your Amazon EFS file system.Note: You can specify custom options for Root directory, Encryption in transit, and EFS IAM authorization. Or, you can accept the default, where "/" is the root directory.9.    Choose Add.10.    In the Containers Definition section, choose Add container.11.    In the STORAGE AND LOGGING section, in the Mount points sub-section, select the volume that you created for Source volume in step 5.12.    For Container path, choose your container path.13.    (Optional) In the ENVIRONMENT section, for Entry point, enter your entry point.14.    For Command, enter the [df ,-h] command to display the mounted file system. Note: You can use the entry point and command to test if your Amazon EFS file system is mounted successfully. By default, the container exits after the df -h command executes successfully. The JSON task definition example in step 16 uses an infinite while loop to keep the task running.15.    Choose Add.16.    Fill out the remaining fields in the task definition wizard, and then choose Create.In the following example, the task definition creates a data volume named efs-test. The nginx container mounts the host data volume at the Any_Container_Path path.{    "family": "sample-fargate-test",    "networkMode": "awsvpc",    "executionRoleArn": "arn:aws:iam::1234567890:role/ecsTaskExecutionRole",    "containerDefinitions": [        {            "name": "fargate-app",            "image": "nginx",            "portMappings": [                {                    "containerPort": 80,                    "hostPort": 80,                    "protocol": "tcp"                }            ],            "essential": true,            "entryPoint": [                "sh","-c"            ],            "command": [                "df -h && while true; do echo \"RUNNING\"; done"            ],            "mountPoints": [                {                    "sourceVolume": "efs-test",                    "containerPath": "Any_Container_Path"                }            ],            "logConfiguration": {              "logDriver": "awslogs",              "options": {                "awslogs-group": "AWS_LOG_GROUP_PATH",                "awslogs-region": "AWS_REGION",                "awslogs-stream-prefix": "AWS_STREAM_PREFIX"              }            }        }    ],    "volumes": [        {            "name": "efs-test",            "efsVolumeConfiguration": {                "fileSystemId": "fs-123xx4x5"            }        }    ],    "requiresCompatibilities": [           "FARGATE"       ],    "cpu": "256",    "memory": "512"}Note: ReplacefileSystemId,logConfiguration,containerPath, and other placeholder values with values for your custom configuration. Also, confirm that your task definition has an execution role Amazon Resource Name (ARN) to support theawslogs log driver.Run a Fargate task and check your task logs1.    Run a Fargate task using the task definition that you created earlier.Important: Be sure to run your task on the Fargate platform version 1.4.0.2.    To verify that your Amazon EFS file system is successfully mounted to your Fargate container, check your task logs.The output of df-h looks similar to the following:2020-10-27 15:15:35Filesystem 1K-blocks Used Available Use% Mounted on2020-10-27 15:15:35overlay 30832548 9859324 19383976 34% /2020-10-27 15:15:35tmpfs 65536 0 65536 0% /dev2020-10-27 15:15:35shm 2018788 0 2018788 0% /dev/shm2020-10-27 15:15:35tmpfs 2018788 0 2018788 0% /sys/fs/cgroup2020-10-27 15:15:35fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ 9007199254739968 0 9007199254739968 0% /Any_Container_Path2020-10-27 15:15:35/dev/xvdcz 30832548 9859324 19383976 34% /etc/hosts2020-10-27 15:15:35tmpfs 2018788 0 2018788 0% /proc/acpi2020-10-27 15:15:35tmpfs 2018788 0 2018788 0% /sys/firmware2020-10-27 15:15:35tmpfs 2018788 0 2018788 0% /proc/scsi RUNNINGRelated informationSecurity in Amazon EFSTutorial: Using Amazon EFS file systems with Amazon ECS using the classic consoleFollow"


Question: How can I allow the tasks in my Amazon ECS services to communicate with each other?

I want to allow the tasks in my Amazon Elastic Container Service (Amazon ECS) services to communicate with each other.

Answer: "I want to allow the tasks in my Amazon Elastic Container Service (Amazon ECS) services to communicate with each other.Short descriptionYou can allow your tasks to communicate with each other using Service discovery. Service discovery helps manage HTTP and DNS namespaces for your Amazon ECS services.Note: Service discovery supports the A and SRV DNS record types. DNS records are automatically added or removed as tasks start or stop in the Amazon ECS service. Tasks or applications that need to connect to your Amazon ECS service can locate an existing task from the DNS record.ResolutionImportant: You can't update an existing service to use service discovery, or modify the service discovery configuration once your service is created. You can only configure service discovery when you create a new service.Before you get started with service discovery, see Service discovery and review Service discovery considerations.Configure service discovery using either the Amazon ECS console or the AWS Command Line Interface (AWS CLI).Important: After you have configured service discovery, use the YourServiceDiscoveryServiceName.YourServiceDiscoveryNamespace format to query DNS records for a service discovery service within your Amazon Virtual Private Cloud (Amazon VPC).Follow"


Question: How do I troubleshoot VPC-to-VPC connectivity through a transit gateway?

"My virtual private clouds (VPCs) are attached to the same AWS Transit Gateway. However, I'm experiencing connectivity issues between the VPCs. How do I troubleshoot this?"

Answer: "My virtual private clouds (VPCs) are attached to the same AWS Transit Gateway. However, I'm experiencing connectivity issues between the VPCs. How do I troubleshoot this?Short descriptionTo troubleshoot connectivity between VPCs attached to the same AWS Transit Gateway, you can either:Check the routing configuration for the AWS Transit Gateway, VPC, and the Amazon EC2 instance.Use Route Analyzer in AWS Network Manager.ResolutionConfirm your routing configurationsConfirm that the VPCs are attached to the same transit gatewayOpen the Amazon Virtual Private Cloud (Amazon VPC) console.From the navigation pane, choose Transit Gateway Attachments.Verify that the VPC attachments are associated with the same Transit Gateway ID.Confirm that the Transit Gateway route table is associated with a VPC attachmentOpen the Amazon VPC console.From the navigation pane, choose Transit gateway route tables.Choose the route tables that are associated with the transit gateway VPC attachment of the source VPC.Choose the Routes tab.Verify that there is a route for Remote VPC IP range with Target as TGW VPC attachment that corresponds to the value for Remote VPC.Choose the route tables that are associated with the transit gateway VPC attachment of the remote VPC.Choose the Routes tab.Verify that there is a route for Source VPC IP range with Target as TGW VPC attachment. Verify that the route corresponds to the value for Source VPC.Confirm that the VPC route table of the source VPC has a route for remote VPC IP range with the gateway set to Transit Gateway.Open the Amazon VPC console.From the navigation pane, choose Route Tables.Select the route table used by the source EC2 instance.Choose the Routes tab.Verify that there's a route for the Remote VPC CIDR block under Destination. Then, verify that the Target is set to Transit Gateway ID.Confirm that the VPC route table of the remote VPC has a route for source VPC IP range with the gateway set to Transit Gateway.Open the Amazon VPC console.From the navigation pane, choose Route Tables.Select the route table that's used by the source EC2 instance.Choose the Routes tab.Verify that there's a route for the Remote VPC CIDR block under Destination. Then, verify that the Target is set to Transit Gateway ID.Check the Availability Zones for the transit gateway VPC attachment for the source and remote VPCsOpen the Amazon VPC console.From the navigation pane, choose Transit Gateway Attachments.Choose the source VPC attachment.Under Details, find the Subnet IDs. Verify that a subnet from the source EC2 instance's Availability Zone is selected.Return to Transit Gateway Attachments. Then, choose the remote VPC attachment.Under Details, find the Subnet IDs. Verify that a subnet from the remote EC2 instance's Availability Zone is selected.To add an Availability Zone to a VPC attachment, choose Actions. Then, modify the Transit Gateway attachment and select any subnet from required Availability Zone.Note: Adding or modifying a VPC attachment subnet can impact data traffic while the attachment is in a Modifying state.Confirm that the Amazon EC2 instance's security group and network access control list (ACL) allows the trafficOpen the Amazon EC2 console.From the navigation pane, choose Instances.Select the instance where you're performing the connectivity test.Choose the Security tab.Verify that the Inbound rules and Outbound rules allow the traffic.Open the Amazon VPC console.From the navigation pane, choose Network ACLs.Select the network ACL that's associated with the subnet where you have the instance.Select the Inbound rules and Outbound rules to verify that the rules allow the traffic.Confirm that the network ACL associated with the transit gateway network interface allows the trafficOpen the Amazon EC2 console.From the navigation pane, choose Network Interfaces.In the search bar, enter Transit Gateway. All network interfaces of the transit gateway appear. Note the Subnet ID associated with the location where the transit gateway interfaces were created.Open the Amazon VPC console.From the navigation pane, choose Network ACLs.In the search bar, enter the subnet ID that you noted in step 3. The network ACL associated with the subnet displays.Confirm that the Inbound rules and Outbound rules of the network ACL allow the remote VPC traffic.Use Route AnalyzerPrerequisite: Complete the steps in Getting started with AWS Network Manager for Transit Gateway networks before proceeding in this section.Once you have created a global network and registered your transit gateway:Access the Amazon VPC console.From the navigation pane, choose Network Manager.Choose the global network where your transit gateway is registered.From the navigation pane, choose Transit Gateway Network. Then, choose Route Analyzer.Fill in the Source and Destination information as needed. Confirm that both Source and Destination have the same transit gateway.Choose Run route analysis.Route Analyzer performs routing analysis and indicates a status of Connected or Not Connected. If the status is Not Connected, then Route Analyzer gives you a routing recommendation. Use the recommendations, then run again the test to confirm connectivity. If connectivity issues continue, see the Confirm your routing configurations section of this article for more troubleshooting steps.Related informationMonitor your transit gatewaysDiagnosing traffic disruption using AWS Transit Gateway Network Manager Route AnalyzerFollow"


Question: Why can't I connect to my Amazon RDS DB or Amazon Aurora DB instance using RDS Proxy?

I can't connect to my Amazon Relational Database Service (Amazon RDS) or Amazon Aurora DB instance through Amazon RDS Proxy.

Answer: "I can't connect to my Amazon Relational Database Service (Amazon RDS) or Amazon Aurora DB instance through Amazon RDS Proxy.Short descriptionYou might experience connection failures with RDS Proxy for multiple reasons. The following issues are common causes for RDS Proxy connection failures, even when RDS Proxy is in the Available state:Security group rules, either at the DB instance or at the RDS Proxy, prevent the connection.RDS Proxy works only within a virtual private cloud (VPC), so connections from outside the private network fail.The DB instance doesn't accept the connection because of modification or because it's in a non-available state.For native user name and password mode: you used incorrect authentication credentials.For AWS Identity and Access Management (IAM) DB authentication: the IAM user or role that's associated with the client isn't authorized to connect with RDS Proxy.ResolutionNote: If you use RDS Proxy with an RDS DB instance or Aurora DB cluster that uses IAM authentication, then all users must authenticate their connections. Make sure that all users who connect through a proxy authenticate their connection with user names and passwords. See Setting up IAM policies for more information about IAM support in RDS Proxy.Check that the client can reach RDS Proxy within the private network of a VPCRDS Proxy can be used only within a VPC, and can't be publicly accessible (although the DB instance can be). If you connect from outside a private network, then your connection times out. Note the following attributes for connecting within a VPC:If the client is from the same VPC, then check that your RDS Proxy's security group allows connections from the client on the default port. The default ports are 3306 for MySQL and 5432 for PostgreSQL. Add rules to the security group associated with the VPC to allow the required traffic.If the client is from another VPC, then use VPC peering. To manage the traffic from the other VPC, review the security group and route tables.If your client is from a corporate network, then use AWS Direct Connect or AWS Site-to-Site VPN to connect directly to the VPC.If your client must connect through the public internet, then use SSH tunneling as an intermediate host. This allows you to connect into the RDS Proxy within the same VPC.Check that RDS Proxy can connect with the DB instanceTo manage the connection pool, RDS Proxy must establish a connection with your DB instance. This connection uses the user name and password that's stored in the AWS Secrets Manager. Use the following best practices to make sure that RDS Proxy can connect with your DB instance:Check that the credentials in the Secrets Manager are valid and can connect to the DB instance.Make sure that your DB instance's security group allows traffic from the RDS Proxy. To do this, first determine the security group of the DB instance and RDS Proxy.If the RDS Proxy and DB instance use the same security group, then verify that the security group's inheritance rule is in the inbound rules:Inbound rules for the RDS instance in order to allow connections from RDS proxy:Protocol : TCPPort Range : Port on which the DB engine is running on the RDS instanceSource : Common security group (for self referencing the security group)If they use different security groups, then mention the RDS Proxy's security group in the inbound rule of the DB instance's security group:Inbound rules for the RDS instance in order to allow connections from RDS proxy:Protocol : TCPPort range : Port on which the DB engine is running on the DB instanceSource : Security group of RDS ProxyThe RDS Proxy initiates the connection to manage the pool. Therefore, you must allow outbound traffic to reach the DB instance. To do this, RDS Proxy security group must allow the required traffic in its outbound rule:Protocol : TCPPort range : Port on which the DB engine is running on the RDS instanceDestination : Security group of DB instanceNote: If you already have the following outbound rules attached to the security group of the RDS Proxy, then there is no need to explicitly add the security group. Outbound rules: ALL --- 0.0.0.0/0Check that the IAM role associated with the RDS Proxy can fetch and use the credentials that are required for connections:The IAM role must have the trust policy for rds.amazonaws.com.The IAM policy must have access to call the secretsmanager:GetSecretValue action on the secret.The IAM policy must have access to call the kms:Decrypt action on the AWS Key Management Service (AWS KMS) key that encrypted the secret. You can get the details of the KMS key that's used by Secrets Manager from the AWS KMS console. Note that the KMS key ID must be used for the Resource section. See the following example policy:{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Action": "secretsmanager:GetSecretValue",      "Resource": [        "arn:aws:secretsmanager:region:account_id:secret:secret_name"      ]    },    {      "Effect": "Allow",      "Action": "kms:Decrypt",      "Resource": "arn:aws:kms:region:account_id:key/key_id",      "Condition": {        "StringEquals": {          "kms:ViaService": "secretsmanager.region.amazonaws.com"        }      }    }  ]}Note: Be sure to replace account_id, secret_name, region, account_id, and key_id with your relevant values.For more information on what might prevent the proxy from connecting to the DB instance, run the describe-db-proxy-targets command. Then, review the TargetHealth structure in the output. Review the State, Reason, and Description fields for more information on the connection health of the RDS Proxy target:aws rds describe-db-proxy-targets --db-proxy-name $DB_PROXY_NAMEFor more information, see Verifying connectivity for a proxy.Check that the DB instance currently accepts connectionsReview the current status of your DB instance and confirm that it's in the AVAILABLE state. For more information on reviewing the status of your DB instance, see the Amazon RDS and Aurora documentation for DB instance status.Check that the IAM user/role is associated with a client with required permissionsNote: This step is required only if you activated IAM DB Authentication on your RDS Proxy.The client must generate a token to authorize the connection request. To do this, the IAM user and IAM role that's associated with this client must have the rds-db:connect IAM policy. Also, make sure to use the RDS Proxy ID in the ARN for the Resources attribute in the policy:"Resource": "arn:aws:rds-db:us-east-2:1234567890:dbuser:prx-ABCDEFGHIJKL01234/db_user"For more information, see Creating and using an IAM policy for IAM database access.Review the RDS Proxy logsTurn on the Enhanced Logging feature of RDS Proxy. Logging gives detailed information about the SQL statements. These logs are a useful resource to help you understand certain authentication issues. Because this adds to performance overhead, it's a best practice to turn them on only for debugging. To minimize overhead, RDS Proxy automatically turns this setting off 24 hours after you turn it on.Related informationUsing Amazon RDS ProxySet up shared database connections with Amazon RDS ProxyFollow"


Question: How do I re-create a terminated EC2 instance?

"My Amazon Elastic Compute Cloud (Amazon EC2) instance was terminated, but I want to recover or restore data from that instance. Can I re-create a terminated EC2 instance?"

Answer: "My Amazon Elastic Compute Cloud (Amazon EC2) instance was terminated, but I want to recover or restore data from that instance. Can I re-create a terminated EC2 instance?ResolutionAs part of an Amazon EC2 instance termination, the data on any instance store volumes associated with that instance is deleted. By default, the root Amazon Elastic Block Store (Amazon EBS) volume is automatically deleted.It's not possible to recover either the original Amazon EC2 instance or any volumes that were deleted as part of the termination process. However, you can use the following methods to re-create the terminated instance:Launch a replacement EC2 instance using Amazon EBS snapshots or Amazon Machine Images (AMI) backups that were created from the terminated Amazon EC2 instance.Attach an EBS volume from the terminated instance to another EC2 instance. You can then access the data contained in those volumes.Use the following methods to prevent instance termination and volume deletion:Enable termination protection of the EBS volume when you launch an EC2 instance. If you enable this option and the instance is later terminated, then the EBS root volume isn't deleted. You can then launch a new EC2 instance from the available root volume. For more information, see How can I prevent my Amazon EBS volumes from being deleted when I terminate Amazon EC2 instances?Set the instance shutdown behavior to stop the instance instead of terminating it. For more information, see Change the instance initiated shutdown behavior.If the instance is part of an Amazon EC2 Auto Scaling group, you can customize the termination policy or use scale-in protection. For more information, see Controlling which Auto Scaling instances terminate during scale in.In addition to regularly taking snapshots and AMIs to back up critical data, consider using termination protection to help prevent this issue in the future. You can also automate snapshots with Amazon Data Lifecycle Manager (Amazon DLM) and AWS Backup.Related informationHow can I recover an accidentally deleted AMI?My Spot Instance was terminated. Can I recover it?How do I protect my data against accidental Amazon EC2 instance termination?Follow"


Question: How do I launch Amazon WorkSpaces with a directory that is currently running in another Region from the same account?

"I want to use Amazon WorkSpaces, but the service isn’t yet available in the AWS Region that I currently use for other AWS services. How can I use my Microsoft Active Directory setup in one Region to use Amazon WorkSpaces in a different Region where the service is available?"

Answer: "I want to use Amazon WorkSpaces, but the service isn’t yet available in the AWS Region that I currently use for other AWS services. How can I use my Microsoft Active Directory setup in one Region to use Amazon WorkSpaces in a different Region where the service is available?ResolutionTo launch Amazon WorkSpaces using a directory in another Region of the same AWS account, follow the steps below.Note: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, then make sure that you’re using the most recent AWS CLI version.Create virtual private cloud (VPC) peering with another VPC in your accountCreate a VPC peering connection with a VPC in a different Region.Accept the VPC peering connection.The VPC peering connection is activated. You can view your VPC peering connections using the Amazon VPC console, the AWS CLI, or an API.Update route tables for VPC peering in both RegionsUpdate your route tables to turn on communication with the peer VPC over IPv4 or IPv6.You now have two VPCs in your account that are in different Regions, but that are talking to each other.Create an AD Connector and register Amazon WorkSpacesReview the AD Connector prerequisites.Connect your existing directory with AD Connector.When the AD Connector status changes to Active, open the AWS Directory Service console, and then choose the hyperlink for your Directory ID.For AWS apps & services, choose Amazon WorkSpaces to turn on access for Amazon WorkSpaces on this directory.Register the directory with Amazon WorkSpaces.When the value of Registered changes to Yes, you can launch a WorkSpace.Related informationCreate with VPCs in different accounts and RegionsFollow"


Question: How can I troubleshoot the AWS STS error “the security token included in the request is expired” when using the AWS CLI to assume an IAM role?

"I tried to assume an AWS Identity and Access Management (IAM) role by using the AWS Command Line Interface (AWS CLI). However, I received an error similar to the following:"The security token included in the request is expired.""

Answer: "I tried to assume an AWS Identity and Access Management (IAM) role by using the AWS Command Line Interface (AWS CLI). However, I received an error similar to the following:"The security token included in the request is expired."Short descriptionTemporary security credentials for IAM users are requested using the AWS Security Token Service (AWS STS) service. Temporary credentials created with the AssumeRole API action last for one hour by default. After temporary credentials expire, they can't be reused. For more information, see Temporary security credentials in IAM.ResolutionUse the following troubleshooting steps for your use case.If you receive errors when running AWS CLI commands, make sure that you’re using the most recent AWS CLI version.Make sure that your temporary security credential requests can reach AWS endpointsEstablishing credentials for a role requires an access key ID, secret access key, and session token. Requests sent must reach the AWS endpoint within five minutes of the timestamp on the request or the request is denied. For more information, see Why requests are signed.Using profiles to assume an IAM roleA named profile is a collection of settings and credentials that you can apply to an AWS CLI command. You must verify that you're using the correct credentials.The following AWS CLI command uses the default profile credentials:aws s3 lsThis example command uses the project1 profile credentials configured in the .config file:aws s3 ls --profile project1Example output using expired credentials:"An error occurred (ExpiredToken) when calling the ListBuckets operation: The provided token has expired."These profiles are defined in your .aws folder containing the .credentials and .config files.The config file is located at ~/.aws/config for Linux/macOS and C:\Users%USERPROFILE%.aws\config for Windows. The credentials file is located at ~/.aws/credentials for Linux/macOS and C:\Users%USERPROFILE%.aws\credentials for Windows.To check your default profile credentials, run the following command:aws configure list --profile defaultExample output:Name Value Type Location---- ----- ---- --------profile default manual —profileaccess_key TGN7 shared-credentials-filesecret_key SbXb shared-credentials-fileregion us-east-1 config-file ~/.aws/configTo confirm that the same credentials are used for the profile project1, run the following command:aws configure list --profile project1Example output:Name Value Type Location---- ----- ---- --------profile project1 manual —profileaccess_key QN2X config-filesecret_key LPYI config-fileregion eu-west-1 config-file ~/.aws/configIn the example output, note that different credentials might be configured for the default and project1 profiles.You can create a profile in your .aws/config file using the following format:[profile project1]region = eu-west-1aws_access_key_id = <access-Key-for-an-IAM-role>aws_secret_access_key = <secret-access-Key-for-an-IAM-role>aws_session_token = <session-token>These credentials are provided to you when you run the AWS STS assume-role command similar to the following:aws sts assume-role --role-arn arn:aws:iam::<account-number>:role/Prod-Role --role-session-name environment-prodExample output:{"AssumedRoleUser": {"AssumedRoleId": "AROAXXXXXXXXXXXX:environment-prod","Arn": "arn:aws:sts::<account-number>:assumed-role/Prod-Role/environment-prod"},"Credentials": {"SecretAccessKey": "<secret-access-Key-for-an-IAM-role>,"SessionToken": "<session-token>","Expiration": "2020-03-31T17:17:53Z","AccessKeyId": "<access-Key-for-an-IAM-role>"}Note: You can increase the maximum session duration expiration for temporary credentials for IAM roles using the DurationSeconds parameter for your use case.The new assume-role API call then retrieves a new set of valid credentials. Following the API call, you must manually update the ~/.aws/config file with the new temporary credentials.You can avoid updating the config file every time a session expires. Define a profile for the IAM role along with the user that assumes the role in the ~/.aws/config or ~/.aws/credentials file similar to the following:[profile project1]role_arn = <arn-of-IAM-role>source_profile = user1region = <region>Note that user1 is defined in your ~/.aws/credentials file similar to the following:[user1]aws_access_key_id=AKIAIOSFODNN7EXAMPLEaws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEYDefining the source_profile means that you don't have to update your temporary credentials in the ~/.aws/config or ~/.aws/credentials file.The following AWS CLI command lists the Amazon Simple Storage Service (Amazon S3) buckets with credentials for user1 located in the ~/.aws/credentials file.aws s3 ls --profile project1If you're using the AWS CLI with a source_profile element, the API call assume-role puts credentials in the .aws/cli/cache file. Expired credentials are automatically updated in the .aws/cli/cache file. If you receive an error for expired credentials, you can clear the cache with the following commands:Linux/macOS:$ rm -r ~/.aws/cli/cacheWindows:C:\> del /s /q %UserProfile%\.aws\cli\cacheThe AWS CLI creates new credentials in the cache.Create environment variables to assume the IAM role and then verify accessYou can use IAM role credentials to create three environment variables to assume the IAM role similar to the following:Linux/macOS:export AWS_ACCESS_KEY_ID=RoleAccessKeyIDexport AWS_SECRET_ACCESS_KEY=RoleSecretKeyexport AWS_SESSION_TOKEN=RoleSessionTokenWindows:C:\> setx AWS_ACCESS_KEY_ID RoleAccessKeyIDC:\> setx AWS_SECRET_ACCESS_KEY RoleSecretKeyC:\> setx AWS_SESSION_TOKEN RoleSessionTokenTo verify that you assumed the correct IAM role, run the following command:aws sts get-caller-identityThe get-caller-identity command displays information about the IAM identity used to authenticate the request. For more information, see How do I assume an IAM role using the AWS CLI?Environment variables hold temporary cached credentials even after they expire and aren't renewed automatically. Use the following commands to check if credential environment variables are set:Linux/macOS:$ printenv | grep AWSWindows:C:\>set AWSYou can remove expired environment variables with the following commands:Linux/macOS:$ unset AWS_ACCESS_KEY_ID$ unset AWS_SECRET_ACCESS_KEY$ unset AWS_SESSION_TOKENWindows:C:\>set AWS_ACCESS_KEY_ID=C:\>set AWS_SECRET_ACCESS_KEY=C:\>set AWS_SESSION_TOKEN=You can now use the assume-role API call again to get new, valid credentials and set the environment variables again.Important: The .aws/credentials and .aws/config files contain credential details for your IAM entities. When managing your credentials, make sure that you follow security best practices in IAM.Related informationRequesting temporary security credentialsHow do I resolve the error ‘The security token included in the request is expired’ when running Java applications on Amazon EC2?Follow"


Question: How does DNS work with my AWS Client VPN endpoint?

I'm creating an AWS Client VPN endpoint. I need to specify the DNS servers that my end users (clients connected to AWS Client VPN) should query for domain name resolution. How does DNS work with my AWS Client VPN endpoint?

Answer: "I'm creating an AWS Client VPN endpoint. I need to specify the DNS servers that my end users (clients connected to AWS Client VPN) should query for domain name resolution. How does DNS work with my AWS Client VPN endpoint?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.You can specify DNS server IP addresses when you create a new Client VPN endpoint. To do this, specify the IP addresses in the "DNS Server IP address" parameter using the AWS Management Console, the AWS CLI, or the API.You can also modify an existing Client VPN endpoint to specify DNS server IP addresses. To do this, modify the "DNS Server IP address" parameter using the AWS Management Console, AWS CLI, or the API.Considerations for configuring the "DNS Server IP address" parameterFor high availability, it's a best practice to specify two DNS servers. If the primary DNS server becomes unreachable, the end user device resends the query to the secondary DNS server.Note: If the primary DNS server responds with "SERVFAIL," the DNS request isn't sent again to the secondary DNS server.Confirm that both of the specified DNS servers can be reached by end users after they connect to the Client VPN endpoint. DNS lookups depend on the "DNS Server IP address" parameter. If the DNS servers are unreachable, then DNS requests might fail and cause connectivity problems.The "DNS Server IP address" parameter is optional. If there's no DNS server specified, then the DNS IP address configured on the end user's device is used to resolve DNS queries.When using AmazonProvidedDNS (or the Route 53 Resolver inbound endpoint) as the Client VPN DNS server:You can resolve the resource records of the Amazon Route 53 private hosted zone associated with the VPC.The Amazon Relational Database Service (Amazon RDS) public hostnames and AWS service endpoint names that are accessible from the VPC interface endpoint (with "Private DNS" enabled) resolve to a private IP address.Note: Be sure that "DNS Resolution" and "DNS Hostnames" are enabled for the associated VPC.Remember that the Client VPN endpoint uses the source NAT to connect to resources in the associated VPCs.After the client device establishes the Client VPN tunnel, the "DNS Server IP address" parameter is applied. It is applied whether it's full-tunnel or split-tunnel.Full-tunnel: After the client device establishes the tunnel, a route for all traffic through the VPN tunnel is added to the end user device's route table. This causes all traffic (including DNS traffic) to be routed through the Client VPN tunnel. The DNS lookup might fail if the Client VPN's associated VPC (subnet) and the Client VPN route table don't have an appropriate route to reach the configured DNS servers.Split-tunnel: When the Client VPN tunnel is established, only the routes present in the Client VPN route table are added to the end user device's route table. If you can reach the DNS server through the Client VPN's associated VPC, be sure to add a route for the DNS server IP addresses in the Client VPN route table.Note: The following examples demonstrate how DNS works in a few common scenarios. These examples apply to both Windows and Linux environments. However, in a Linux environment, the examples function as described only if the end user's host machine uses the generic networking setting.Scenario #1: Full-tunnel with the "DNS Server IP address" parameter disabledExample 1:The end user client's IPv4 CIDR = 192.168.0.0/16.The Client VPN endpoint VPC's CIDR = 10.123.0.0/16.Local DNS server IP address = 192.168.1.1.The "DNS Server IP address" parameter is disabled (there are no DNS server IP addresses specified).Because the "DNS Server IP address" parameter is disabled, the end user's host machine uses the local DNS server to resolve DNS queries.This Client VPN is configured in full-tunnel mode. A route pointing to the virtual adapter is added to send all traffic over the VPN (destination 0/1 over utun1). However, DNS traffic still doesn't travel over the VPN, because the "DNS Server IP address" parameter is not configured. DNS traffic between the client and the DNS server remains local. The client machine already has a preferred static route to the local DNS server IP (dest. 192.168.1.1/32 over en0) to make that the local DNS resolver is reachable. After the domain name is resolved to the respective IP, the application traffic to the resolved IP travels over the VPN tunnel.Below is a snippet of this example:$ cat /etc/resolv.conf | grep nameservernameserver 192.168.1.1$ netstat -nr -f inet | grep -E 'utun1|192.168.1.1'0/1                192.168.0.1        UGSc           16        0   utun1192.168.1.1/32     link#4             UCS             1        0     en0(...)$ dig amazon.com;; ANSWER SECTION:amazon.com.32INA176.32.98.166;; SERVER: 192.168.1.1#53(192.168.1.1)(...)Example 2:The end user client's IPv4 CIDR = 192.168.0.0/16.The Client VPN endpoint VPC's CIDR = 10.123.0.0/16.The local DNS server IP address is set to public IP = 8.8.8.8.The "DNS Server IP address" parameter is disabled (there are no DNS server IP addresses specified).In this scenario, rather than using the local DNS server at 198.168.1.1, the client uses a public DNS as their local DNS server IP address (in this example, 8.8.8.8). Because there's no static route for 8.8.8.8 using en0, traffic destined to 8.8.8.8 travels over the Client VPN tunnel. If the Client VPN endpoint isn't configured to access the internet, then the public DNS (8.8.8.8) is unreachable and request queries time out.$ cat /etc/resolv.conf | grep nameservernameserver 8.8.8.8$ netstat -nr -f inet | grep -E 'utun1|8.8.8.8'0/1                192.168.0.1      UGSc            5        0   utun1$ dig amazon.com(...);; connection timed out; no servers could be reachedScenario #2: Split-tunnel with the "DNS Server IP address" parameter enabledIn this example:The end user client's IPv4 CIDR = 192.168.0.0/16.The Client VPN endpoint's VPC CIDR = 10.123.0.0/16.The "DNS Server IP address" parameter is enabled and set to 10.10.1.228 and 10.10.0.43. These IP addresses represent the IP addresses of the Route 53 Resolver's inbound endpoints that are present in another VPC (10.10.0.0/16) connected with a transit gateway to the Client VPN endpoint's associated VPC.The associated VPC has "DNS Hostnames" and "DNS Support" enabled, and has an associated Route 53 private hosted zone (example.local).This Client VPN is configured in split-tunnel mode. The routes in the Client VPN route table are added to the route table of the end user's host machine:$ netstat -nr -f inet | grep utun1(...)10.10/16           192.168.0.1        UGSc            2        0   utun1 # Route 53 Resolver inbound endpoints VPC CIDR10.123/16          192.168.0.1        UGSc            0        0   utun1 # Client VPN VPC CIDR(...)Because the "DNS Server IP address" parameter is enabled, and 10.10.1.228 and 10.10.0.43 are configured as the DNS servers, these DNS server parameters are pushed to the end user's host machine when the client establishes the VPN tunnel:$ cat /etc/resolv.conf | grep nameservernameserver 10.10.1.228 # Primary DNS server nameserver 10.10.0.43 # Secondary DNS serverA DNS query issued by the client machine travels over the VPN tunnel to the Client VPN VPC. Next, the DNS request is source NATed and forwarded to the Amazon Route 53 Resolver endpoint over a transit gateway. After the domain is resolved to an IP address, application traffic also travels over the established VPN tunnel (as long as the resolved destination IP matches a route from the Client VPN endpoint route table).Using this configuration, end users can resolve:External domain names using standard DNS resolution.Records from private hosted zones associated with the Route 53 Resolver VPC.Interface endpoint DNS names and EC2 public DNS hostnames.$ dig amazon.com;; ANSWER SECTION:amazon.com.8INA176.32.103.205;; SERVER: 10.10.1.228#53(10.10.1.228)(...)$ dig test.example.local # Route 53 private hosted zone record ;; ANSWER SECTION:test.example.local. 10 IN A 10.123.2.1;; SERVER: 10.10.1.228#53(10.10.1.228)(...)$ dig ec2.ap-southeast-2.amazonaws.com # VPC interface endpoint to EC2 service in Route 53 Resolver VPC;; ANSWER SECTION:ec2.ap-southeast-2.amazonaws.com. 60 INA10.10.0.33;; SERVER: 10.10.1.228#53(10.10.1.228)(...)$ dig ec2-13-211-254-134.ap-southeast-2.compute.amazonaws.com # EC2 instance public DNS hostname running in Route 53 Resolver VPC;; ANSWER SECTION:ec2-13-211-254-134.ap-southeast-2.compute.amazonaws.com. 20 IN A 10.10.1.11;; SERVER: 10.10.1.228#53(10.10.1.228)(...)Follow"


Question: How do I migrate my SSL certificate to the US East (N. Virginia) Region for use with my CloudFront distribution?

"I have an SSL certificate in AWS Certificate Manager (ACM) that I want to associate with my Amazon CloudFront distribution. However, I can't associate the certificate with the distribution because it's not in the US East (N. Virginia) (us-east-1) Region. Can I move the certificate to US East (N. Virginia)?"

Answer: "I have an SSL certificate in AWS Certificate Manager (ACM) that I want to associate with my Amazon CloudFront distribution. However, I can't associate the certificate with the distribution because it's not in the US East (N. Virginia) (us-east-1) Region. Can I move the certificate to US East (N. Virginia)?ResolutionYou can't migrate an existing certificate in ACM from one AWS Region to another. Instead, you must import or create a certificate in the target Region.To associate an ACM certificate with a CloudFront distribution, you must import or create the certificate in US East (N. Virginia). Additionally, the certificate must meet the CloudFront requirements.Follow these steps to import or create an ACM certificate for use with a CloudFront distribution:Open the ACM console in the US East (N. Virginia) Region.Note: From the AWS Region selector in the navigation bar, confirm that N. Virginia is selected.Proceed with the steps to import a certificate using the console, or request a certificate using the console.After the certificate is imported or validated successfully, you can associate the certificate and alternate domain names (CNAMEs) with your CloudFront distribution.Related informationIssuing and managing certificatesFollow"


Question: How do I upload an image or PDF file to Amazon S3 through API Gateway?

I want to upload an image or PDF file to Amazon Simple Storage Service (Amazon S3) through Amazon API Gateway. I also want to retrieve an image or PDF file.

Answer: "I want to upload an image or PDF file to Amazon Simple Storage Service (Amazon S3) through Amazon API Gateway. I also want to retrieve an image or PDF file.Short descriptionTo upload an image or PDF as a binary file to an Amazon S3 bucket through API Gateway, activate binary support.To grant your API access to your S3 bucket, create an AWS Identity and Access Management (IAM) role. The IAM role must include permissions for API Gateway to perform the PutObject and GetObject actions on your S3 bucket.ResolutionCreate an IAM role for API Gateway1.    Open the IAM console.2.    In the navigation pane, choose Roles.3.    Choose Create role.4.    In the Select type of trusted entity section, choose AWS service.5.    In the Choose a use case section, choose API Gateway.6.    In the Select your use case section, choose API Gateway.7.    Choose Next: Permissions.Note: This section shows the AWS managed service that permits API Gateway to push logs to a user's account. You add permissions for Amazon S3 later.8.    (Optional) Choose Next: Tags to add tags.9.    Choose Next: Review.10.    For Role name, enter a name for your policy. For example: api-gateway-upload-to-s3.11.    Choose Create role.Create and attach an IAM policy to the API Gateway role1.    Open the IAM console.2.    In the navigation pane, choose Roles.3.    In the search box, enter the name of the new API Gateway role that you created. Then, choose that role from the Role name column.4.    On the Roles detail page tab, choose Add permissions.5.    Choose Create inline policy.6.    On the Visual editor tab, in the Select a service section, choose Choose a service.7.    Enter S3, and then choose S3.8.    In the Specify the actions allowed in S3 box, enter PutObject, and then choose PutObject.9.    Enter GetObject, and then choose GetObject.10.    Expand Resources, and then choose Specific.11.    Choose Add ARN.12.    For Bucket name, enter the name of your bucket. Include the prefix, if applicable.13.    For Object name, enter an object name.Note: The bucket name specifies the location of the uploaded files. The object name specifies the pattern that the object must adhere to for policy alignment. For more information, see Bucket naming rules and Amazon S3 objects overview.14.    Choose Add.15.    (Optional) Choose Next: Tags to add tags.16.    Choose Next: Review.17.    For Name, enter the name of your policy.18.    Choose Create policy.19.    In the policy search box, enter the name of the policy that you created in step 17, and then select that policy.20.    Choose Policy actions, and then choose Attach. A list of IAM roles appears.21.    Search for the API Gateway role that you created earlier. Then, select the role.22.    Choose Attach policy.Create an API Gateway REST APICreate an API to serve your requests1.    Open the API Gateway console.2.    In the navigation pane, choose APIs.3.    Choose Create API.4.    In the Choose an API type section, for REST API, choose Build.5.    For API Name, enter a name for your API, and then choose Next.6.    Choose Create API.Create resources for your API1.    In the Resources panel of your API page, select /.2.    For Actions, choose Create Resource.3.    For Resource Name, enter folder.4.    For Resource Path, enter {folder}.5.    Choose Create Resource.6.    In the Resources panel, select the /{folder} resource that you created in step 5.7.    Choose Actions, and then choose Create Resource.8.    For Resource Name, enter object.9.    For Resource Path, enter {object}.10.    Choose Create Resource.Create a PUT method for your API for uploading image or PDF1.    Choose Actions, and then choose Create Method.2.    From the dropdown list, choose PUT, and then choose the check mark icon.3.    Under the Integration type category, choose AWS Service.4.    For AWS Region, choose us-east-1 or the AWS Region you see on the Bucket properties page.5.    For AWS Service, choose Simple Storage Service (S3).6.    Keep AWS Subdomain empty.7.    For HTTP method, choose PUT.8.    For Action Type, choose Use path override.9.    For Path override (optional), enter {bucket}/{key}.10.    For Execution role, enter the ARN for the IAM role that you created earlier. ARN creation is part of the Create and attach an IAM policy to the API Gateway role section.11.    For Content Handling, choose Passthrough.12.    Choose Save.Configure parameter mappings for the PUT method1.    In the Resources panel of your API page, choose PUT.2.    Choose Integration Request.3.    Expand URL Path Parameters.4.    Choose Add path.5.    For Name, enter bucket.6.    For Mapped from, enter method.request.path.folder.7.    Choose the check mark icon at the end of the row.8.    Repeat steps 4–7. In step 5, set Name to key. In step 6, set Mapped from to method.request.path.object.Create a GET method for your API for retrieving an image1.    In the Resources panel of your API page, choose /{object}.2.    Choose Actions, and then choose Create Method.3.    From the dropdown list, choose GET, and then choose the check mark icon.4.    Under the Integration type category, choose AWS Service.5.    For AWS Region, choose us-east-1, or the Region that you see on the Bucket properties page.6.    For AWS Service, choose Simple Storage Service (S3).7.    Keep AWS Subdomain empty.8.    For HTTP method, choose GET.9.    For Action Type, choose Use path override.10.    For Path override (optional), enter {bucket}/{key}.11.    For Execution role, enter the ARN for the IAM role that you created earlier. ARN creation is part of the Create and attach an IAM policy to the API Gateway role section.12.    For Content Handling, choose Passthrough.13.    Choose Save.Configure parameter mappings for the GET method1.    In the Resources panel of your API page, choose GET.2.    Choose Integration Request.3.    Expand URL Path Parameters.4.    Choose Add path.5.    For Name, enter bucket.6.    For Mapped from, enter method.request.path.folder.7.    Choose the check mark icon at the end of the row.8.    Repeat steps 4–7. In step 5, set Name to key. In step 6, set Mapped from to method.request.path.object.Set up response mapping to see the image or PDF in browser1.    In the Resources panel of your API page, choose GET.2.    Choose Method Response.3.    Expand 200.4.    Under Response Body for 200, remove application/json.5.    Under Response headers for 200, choose Add header.6.    For Name, enter content-type.7.    Choose the check mark icon to save.8.    Choose Method execution to go back to the Method Execution pane.9.    Choose Integration Response.10.    Expand 200, and then expand Header Mappings.11.    Choose the pencil icon at end of the row named content-type.12.    Enter 'image/jpeg' to see an image file.-or-Enter 'application/pdf' to see a PDF file.Set up binary media types for the API1.    In the navigation pane of your API page, choose Settings.2.    In the Binary Media Types section, choose Add Binary Media Type.3.    In the text box, add the following string: */*Note: Don't put the string in quotes. You can substitute a wildcard for a particular Multipurpose Internet Mail Extensions (MIME) type that you want to treat as a binary media type. For example, to have API Gateway treat JPEG images as binary media types, choose 'image/jpeg'. If you add */*, then API Gateway treats all media types as binary media types.4.    Choose Save Changes.Resolve CORS error with binary settings for API1.    If you use the previously noted APIs (PUT and GET) in a web application, then you might encounter a CORS error. For more information, see CORS errors on the Mozilla website.2.    To resolve the CORS error with binary settings turned on, start CORS from the API Gateway console.3.    In the Resources panel of your API page, select /{object}.4.    For Actions, choose Enable CORS.5.    Choose Enable CORS and replace existing CORS headers.6.    To update the content handling property, run the update-integration CLI command. This update allows the binary content to handle preflight options requests with mock integration.7.    Update the API ID, Resource ID, and AWS Region to run the following two CLI commands. To obtain the API ID and Resource ID, select the {object} resource from the top of the Gateway API console.aws apigateway update-integration --rest-api-id API_ID --resource-id RESOURCE_id --http-method OPTIONS --patch-operations op='replace',path='/contentHandling',value='CONVERT_TO_TEXT' --region AWS_REGIONaws apigateway update-integration-response --rest-api-id API_ID --resource-id RESOURCE_id --http-method OPTIONS --status-code 200 --patch-operations op='replace',path='/contentHandling',value='CONVERT_TO_TEXT' --region AWS_REGIONDeploy your API1.    In the navigation pane on your API page, choose Resources.2.    In the Resources pane, choose Actions, and then choose Deploy API.3.    In the Deploy API window, for Deployment stage, choose [New Stage].4.    For Stage name, enter v1.5.    Choose Deploy.6.    In the navigation pane, choose Stages.7.    Choose the v1 stage. The invoke URL for making requests to the deployed API snapshot appears.8.    Copy the invoke URL.Note: For more information, see Deploying a REST API in Amazon API Gateway.Invoke your API to upload an image file to S3Append the bucket name and file name of the object to your API's invoke URL. Then, make a PUT HTTP request with a client of your choice. For example, with the Postman external application, choose PUT method from the dropdown. Choose Body, and then choose binary. When the Select File button appears, select a local file to upload.For more information, see Invoking a REST API in Amazon API Gateway.Example curl command to make a PUT HTTP request to upload an image or PDFIn the following example, abc12345 is your API ID, testfolder is your S3 bucket, and testimage.jpeg is the local file that you upload:curl -i --location --request PUT 'https://abc12345.execute-api.us-west-2.amazonaws.com/v1/testfolder/testimage.jpeg' --header 'Content-Type: text/plain' --data-binary '@/Path/to/file/image.jpeg'Important: If */* is included in the binary media types list, then you can make a PUT request to upload the file. If image.jpeg is included in the binary media types list, then you must add Content-Type header to your PUT request. You must set Content-Type header to 'image/jpeg'.You now see the image or PDF in a web browser with the same URL. This is because the web browser makes a GET request.Related informationActivating binary support using the API Gateway REST APIFollow"


Question: How can I troubleshoot connectivity failures between AWS DMS and a MongoDB source endpoint?

The connectivity between my AWS Database Migration Service (AWS DMS) replication instance and my MongoDB source endpoint failed. How can I troubleshoot "Test Endpoint failed" errors when using MongoDB as the source endpoint?

Answer: "The connectivity between my AWS Database Migration Service (AWS DMS) replication instance and my MongoDB source endpoint failed. How can I troubleshoot "Test Endpoint failed" errors when using MongoDB as the source endpoint?ResolutionA MongoDB source endpoint can fail to connect for several reasons. See the following common errors and their resolutions.Connection timeout calling errorsIf an AWS DMS replication instance can't connect to the MongoDB database that is specified, you receive the following error:Test Endpoint failed: Application-Status: 1020912, Application-Message: Failed to create new client connection Failed to connect to database., Application-Detailed-Message: Error verifying connection: 'No suitable servers found (`serverSelectionTryOnce` set): [connection timeout calling ismaster on 'mongodbtest.us-west-2.compute.amazonaws.com:27017']' Failed to connect to database.This error occurs when connectivity can't be established between the AWS DMS replication instance to the MongoDB database. Most often, this is caused by configuration issues in the security groups, network access control lists (network ACLs), or on-premises firewalls and IP address tables. To resolve this error, confirm that your network is configured to meet the connectivity requirements for AWS DMS replication instances.Connection refused calling errorsWhen the connection request from the AWS DMS replication instance is refused by the MongoDB instance, you receive the following error:Test Endpoint failed: Application-Status: 1020912, Application-Message: Failed to create new client connection Failed to connect to database., Application-Detailed-Message: Error verifying connection: 'No suitable servers found (`serverSelectionTryOnce` set): [connection refused calling ismaster on 'mongodbtest.us-west-2.compute.amazonaws.com:27017']' Failed to connect to database.This error occurs when the the bindIp settings on the MongoDB database don't allow access to connections from replication instances. To resolve this error, modify  the bindIp configuration on the MongoDB instance to allow connections from replication instances. For more information, see the MongoDB documentation for IP Binding.Authentication failed errorsWhen the credentials provided aren't correct or use a special character, you receive the following error:Test Endpoint failed: Application-Status: 1020912, Application-Message: Failed to create new client connection Failed to connect to database., Application-Detailed-Message: Error verifying connection: 'Authentication failed.' Failed to connect to database.<br>This error occurs when the user name or password provided in the endpoint are incorrect, the authentication source database provided the for the user name field is incorrect, or you used a special character in your password that MongoDB doesn't accept. For more information, see Creating Source and Target Endpoints.To resolve this error, confirm that you have the correct authentication credentials by connecting to the MongoDB database using the user name and password provided in the endpoint.Libmongoc version errorsWhen you use a version of MongoDB that isn't supported for AWS DMS replication, you receive the following error:Test Endpoint failed: Application-Status: 1020912, Application-Message: Failed to create new client connection Failed to connect to database., Application-Detailed-Message: Error verifying connection: 'Server at ec2-35-166-73-109.us-west-2.compute.amazonaws.com:27017 reports wire version 2, but this version of libmongoc requires at least 3 (MongoDB 3.0)' Failed to connect to database.To resolve this error, upgrade the source MongoDB database to a version of MongoDB that is supported by AWS DMS.Related informationUsing MongoDB as a Source for AWS DMSHow can I troubleshoot AWS DMS endpoint connectivity failures?Follow"


Question: How do I use CloudTrail to review what API calls and actions have occurred in my AWS account?

"How do I review actions that occurred in my AWS account, such as console logins or terminating an instance?"

Answer: "How do I review actions that occurred in my AWS account, such as console logins or terminating an instance?Short descriptionYou can use AWS CloudTrail data to view and track API calls made to your account using the following:CloudTrail Event historyCloudTrail LakeAmazon CloudWatch LogsAmazon Athena queriesAmazon Simple Storage Service (Amazon S3) archived log filesNote: Not all AWS services have logs recorded and available with CloudTrail. For a list of AWS services integrated with CloudTrail, see AWS service topics for CloudTrail.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.CloudTrail Event historyReviewing CloudTrail Event history using the CloudTrail consoleYou can view all supported services and integrations and event types (create, modify, delete, and non-mutable activities) from the past 90 days. You don't need to set up a trail to use CloudTrail Event history.For instructions, see Viewing CloudTrail events in the CloudTrail console.Reviewing CloudTrail Event history using the AWS CLINote: To search for events using the AWS CLI, you must have a trail created and configured to log to CloudWatch Logs. For more information, see Creating a trail. Also, Sending events to CloudWatch Logs.Use the filter-log-events command to apply metric filters to search for specific terms, phrases, and values in your log events. Then, you can transform them into CloudWatch metrics and alarms.For more information, see Filter and pattern syntax.Note: To use the filter-log-events command at scale (for example, automation or a script), it's a best practice to use CloudWatch Logs subscription filters. This is because the filter-log-events API action has API limits. Subscription filters have no such limits. Subscription filters also provide the ability to process large amounts of log data in real time. For more information, see CloudWatch Logs quotas.CloudTrail LakeCloudTrail Lake allows you to aggregate, immutably store, and run SQL-based queries on your events. You can store even data in CloudTrail Lake for up to seven years, or 2,555 days.For more information, see Working with AWS CloudTrail Lake.Amazon CloudWatch LogsNote: To use CloudWatch Logs, you must have a trail created and configured to log to CloudWatch Logs. For more information, see Creating a trail. Also, Sending events to CloudWatch Logs.You can use CloudWatch Logs to search for operations that change the state of a resource (for example, StopInstances). You can also use CloudWatch Logs to search for operations that don't change the state of a resource (for example, DescribeInstances). For instructions, see View log data sent to CloudWatch Logs.Keep in mind the following:You must explicitly configure CloudTrail to send events to CloudWatch Logs, even if you already created a trail.You can't review activity from before the logs were configured.There can be multiple log streams, depending on the size and volume of events. To search across all streams, choose Search Log Group before selecting an individual stream.Because CloudWatch Logs has an event size limitation of 256 KB, CloudTrail doesn't send events larger than 256 KB to CloudWatch Logs.Amazon Athena queriesYou can use Amazon Athena to view CloudTrail data events and management events stored in your Amazon S3 bucket.For more information, see How do I automatically create tables in Amazon Athena to search through AWS CloudTrail logs? Also, Creating the table for CloudTrail logs in Athena using manual partitioning.Amazon S3 archived log filesNote: To view Amazon S3 archived log files, you must have a trail created and configured to log to an S3 bucket. For more information, see Creating a trail.You can see all events captured by CloudTrail in the Amazon S3 log files. You can also manually parse the log files from the S3 bucket Using the CloudTrail Processing Library, the AWS CLI, or send logs to AWS CloudTrail partners.For instructions, see Amazon S3 CloudTrail events.Note: You must have a trail activated to log to an S3 bucket.Related informationWhat is Amazon CloudWatch Logs?Creating metrics from log events using filtersAWS Config console now displays API events associated with configuration changesCreating CloudWatch alarms for CloudTrail events: examplesFollow"


Question: What are the differences between Amazon EC2 and Amazon Lightsail?

I want to use virtual servers to run my applications. What are the differences between Amazon Elastic Compute Cloud (Amazon EC2) and Amazon Lightsail?

Answer: "I want to use virtual servers to run my applications. What are the differences between Amazon Elastic Compute Cloud (Amazon EC2) and Amazon Lightsail?ResolutionAWS offers Amazon EC2 and Lightsail for hosting applications. Amazon EC2 is a mix of multiple services and has its own individual features used to create a single architecture. Amazon EC2 instances are meant for small to complex architecture. Lightsail, on other hand, is an integrated product of services offered by AWS. Lightsail is better for small to medium scale workloads.Choosing the right architecture is always based on your application's requirements. There are few points that you can use to help you decide which service will work best for your needs. The following are the main differences between Amazon EC2 and Lightsail:Amazon LightsailAmazon EC2UsageUsed for simple web applications and websites, including custom code, and common CMS.Used for small scale to Enterprise applications such as HPC, big data, and analytics workloads.PerformanceUsed for applications with workloads ranging from small to medium.Used for small scale to higher workloads with complex architecture.EaseDeploying applications in Lightsail can be done with few clicks.Provides an all-in-one experience.Deploying application in Amazon EC2 varies due to multiple factors, such as the type of application, the type of components used, and so on. Each component has its own characteristics and features that can be modified in their respective consoles.Administrative supportLess system admin and system architect efforts are needed in Lightsail.Based on the type of environment, the administrative effort varies. Most of the services in EC2 require a thorough understanding about the components.NetworkManaged by AWS. Customers can add rules to Lightsail firewall.Managed by the customer using VPC and related components.SubnetsLightsail has no concept of private subnets.Customers can create subnets as public or private based on their application needs.ScalabilityAutomatic instance scalability isn't supported in Lightsail.Instances can't be modified after launch. You must launch a new instance to change your plan.Instances can be scaled automatically using an Amazon EC2 Auto Scaling group.EC2 instances can be modified to a new type or to a new virtualization.Flexibility in managing resourcesMinimal flexibility in managing resources such as network, hard disk, load balancer, and so on.Customers can manage all the related components based on the application demands.Elastic volumesNot supportedSupportedResource managementAll resources are managed from the same dashboard.Each resource has its own console and options.PricingPrices are low and there is a fixed pricing model.Pricing follows the pay as you go model.Load balancingThe Lightsail load balancer is available for use with Lightsail instances.There are multiple types of load balancers available.MonitoringMonitoring is available, but is restricted to a few options.Detailed monitoring options are available using Amazon Cloudwatch.BackupBackups are available by using Lightsail snapshots.Backups are available as snapshots and AMIs.EncryptionEncryption is enabled by default and is managed by AWS.Customers can choose to enable or disable encryption.Free tierThe free tier is available for 3 months from the day of signing up.The free tier is available for 12 months from the day of signing up.SupportSupport is provided by the AWS Support team. The scope of troubleshooting application level issues is limited.Support is provided by the AWS Support team. The scope of troubleshooting application level issues is limited.For more information, see Amazon Lightsail or Amazon EC2.For more information about limitations in Lightsail, see What should I consider before choosing Lightsail over Amazon EC2?Follow"


Question: How do I remove rate limiting for bulk resource record operations in a Route 53 hosted zone?

My account is rate throttled (API throttled) when I perform bulk resource record operations on my Amazon Route 53 hosted zone.

Answer: "My account is rate throttled (API throttled) when I perform bulk resource record operations on my Amazon Route 53 hosted zone.Short descriptionWhen you are performing bulk resource record operations for your hosted zone in Route 53, you might receive an HTTP 400 (Bad Request) error. A response header that contains a Code element with a value of Throttling and a Message element with a value of Rate exceeded indicates rate throttling.Warning: Rate throttling happens when the number of API requests is greater than the hard limit of five requests per second (per account).If Route 53 can't process the request before the next request for the same hosted zone arrives, it rejects subsequent requests with another HTTP 400 error. The response header contains a Code element with a value of PriorRequestNotComplete and a Message element with a value of the request was rejected because Route 53 was still processing a prior request.Note: API calls by IAM users within the same account count towards global rate throttling for the account and affect API calls made from the AWS Management Console.ResolutionYou can use the following methods to avoid rate throttling:Batching requestsGroup individual operations of the same type into one change batch operation to reduce API calls.Note: UPSERT requests (update and insert) are counted twice.For example, you could request to CREATE, DELETE, or LIST many records with one batch operation.Using error retries and exponential backoffAdd error retries and exponential backoff to your Route 53 API calls.For example, use a simple exponential backoff algorithm that retries the call in 2^i seconds, where i is the number of retries.Randomizing start timesRandomize the start time for calling Route 53 APIs. Be sure that there aren't multiple applications executing the logic at the same time, because simultaneous requests can cause throttling.Introducing "sleep time" between callsIf the code function calls to Route 53 APIs are consecutive, add "sleep time" in between two calls to minimize throttling risk.Note: If your account is still rate throttled after using these troubleshooting methods, open a support case with Route 53 for assistance to locate the source IP address of the API calls that exceed the per second threshold. Then, you can shut off unnecessary sources, or use these troubleshooting methods to resolve the issue.Related informationLimits – Amazon Route 53Follow"


Question: How do I resolve the error "unable to create input format" in Athena?

"When I run a query in Amazon Athena, I get the error "unable to create input format"."

Answer: "When I run a query in Amazon Athena, I get the error "unable to create input format".ResolutionThere are multiple causes of this error. Here are some common scenarios and solutions:The AWS Glue crawler can't classify the data formatThe data is stored in Amazon Simple Storage Service (Amazon S3).You run an AWS Glue crawler with a built-in classifier to detect the table schema. The crawler returns a classification of UNKNOWN. At least one column is detected, but the schema is incorrect.When you query the table from Athena, the query fails with the error "HIVE_UNKNOWN_ERROR: Unable to create input format".To resolve this error, use a data type that is supported by a built-in classifier. If the data format can't be classified by a built-in classifier, then consider using a custom classifier.Athena doesn't support the data formatThe data is stored in Amazon S3.You run a crawler to create the table. The crawler classifies the table in a format that Athena doesn't support, such as ion or xml.When you query the table from Athena, the query fails with the error "HIVE_UNKNOWN_ERROR: Unable to create input format".To resolve this error, use a data format that Athena supports.One or more of the AWS Glue table definition properties are emptyThe AWS Glue table isn't created in Athena or by an AWS Glue crawler. The table is created using any other method. For example, the table is created manually on the AWS Glue console.When you query the table from Athena, the query fails with the error "HIVE_UNKNOWN_ERROR: Unable to create input format".This error occurs because one or more of the following properties in the AWS Glue table definition are empty:Input formatOutput formatSerde nameConfirm that these properties are set correctly for the SerDe and data format. Keep in mind that the SerDe that you specify defines the table schema. The SerDe can override the DDL configuration that you specify in Athena when you create your table.To update the table definition properties, do the following:Open the AWS Glue console.Select the table that you want to update.Choose Action, and then choose View details.Choose Edit table.Update the settings for Input format, Output format, or Serde name.Choose Apply.The data source in your Athena query is not supportedAthena supports querying tables only if the tables are stored in Amazon S3. You might get the "unable to create input format" error if you query a data source that's not supported by Athena.To resolve this error, use Athena Query Federation SDK. The SDK allows you to customize Athena with your own code. With Athena Federation SDK, you can integrate with different data sources and proprietary data formats. You can also build new user-defined functions. For more information, see Query any data source with Amazon Athena’s new federated query.Related informationAdding classifiers to a crawlerUsing a SerDeFollow"


Question: How do I resolve the error "Container killed by YARN for exceeding memory limits" in Spark on Amazon EMR?

I want to troubleshoot the error "Container killed by YARN for exceeding memory limits" in Spark on Amazon EMR.

Answer: "I want to troubleshoot the error "Container killed by YARN for exceeding memory limits" in Spark on Amazon EMR.Short descriptionUse one of the following methods to resolve this error:Increase memory overhead.Reduce the number of executor cores.Increase the number of partitions.Increase driver and executor memory.ResolutionThe root cause and the appropriate solution for this error depends on your workload. You might have to try each of the following methods, in the following order, to troubleshoot the error. Before you continue to the next method in this sequence, reverse any changes that you made to spark-defaults.conf in the preceding section.Increase memory overheadMemory overhead is the amount of off-heap memory allocated to each executor. By default, memory overhead is set to either 10% of executor memory or 384, whichever is higher. Memory overhead is used for Java NIO direct buffers, thread stacks, shared native libraries, or memory mapped files.Consider making gradual increases in memory overhead, up to 25%. The sum of the driver or executor memory plus the memory overhead must be less than the yarn.nodemanager.resource.memory-mb for your instance type.spark.driver/executor.memory + spark.driver/executor.memoryOverhead < yarn.nodemanager.resource.memory-mbIf the error occurs in the driver container or executor container, consider increasing memory overhead for that container only. You can increase memory overhead while the cluster is running, when you launch a new cluster, or when you submit a job.On a running cluster:Modify spark-defaults.conf on the master node.For example:sudo vim /etc/spark/conf/spark-defaults.confspark.driver.memoryOverhead 512spark.executor.memoryOverhead 512On a new cluster:Add a configuration object similar to the following when you launch a cluster:[  {    "Classification": "spark-defaults",    "Properties": {      "spark.driver.memoryOverhead": "512",      "spark.executor.memoryOverhead": "512"    }  }]For a single job:Use the --conf option to increase memory overhead when you run spark-submit.For example:spark-submit --class org.apache.spark.examples.SparkPi --master yarn --deploy-mode cluster --conf spark.driver.memoryOverhead=512 --conf spark.executor.memoryOverhead=512 /usr/lib/spark/examples/jars/spark-examples.jar 100If increasing the memory overhead doesn't solve the problem, then reduce the number of executor cores.Reduce the number of executor coresThis reduces the maximum number of tasks that the executor can perform, which reduces the amount of memory required. Depending on the driver container throwing this error or the other executor container that's getting this error, consider decreasing cores for the driver or the executor.On a running cluster:Modify spark-defaults.conf on the master node.For example:sudo vim /etc/spark/conf/spark-defaults.confspark.driver.cores  3spark.executor.cores  3On a new cluster:Add a configuration object similar to the following when you launch a cluster:[  {    "Classification": "spark-defaults",    "Properties": {"spark.driver.cores" : "3",      "spark.executor.cores": "3"    }  }]For a single job:Use the --executor-cores option to reduce the number of executor cores when you run spark-submit.For example:spark-submit --class org.apache.spark.examples.SparkPi --master yarn --deploy-mode cluster --executor-cores 3 --driver-cores 3 /usr/lib/spark/examples/jars/spark-examples.jar 100If you still get the error message, increase the number of partitions.Increase the number of partitionsTo increase the number of partitions, increase the value of spark.default.parallelism for raw Resilient Distributed Datasets, or run a .repartition() operation. Increasing the number of partitions reduces the amount of memory required per partition. Spark heavily uses cluster RAM as an effective way to maximize speed. Therefore, you must monitor memory usage with Ganglia, and then verify that your cluster settings and partitioning strategy meet your growing data needs. If you still get the "Container killed by YARN for exceeding memory limits" error message, increase the driver and executor memory.Increase driver and executor memoryIf the error occurs in either a driver container or an executor container, consider increasing memory for either the driver or the executor, but not both. Be sure that the sum of driver or executor memory plus driver or executor memory overhead is always less than the value of yarn.nodemanager.resource.memory-mb for your EC2 instance type:spark.driver/executor.memory + spark.driver/executor.memoryOverhead < yarn.nodemanager.resource.memory-mbOn a running cluster:Modify spark-defaults.conf on the master node.Example:sudo vim /etc/spark/conf/spark-defaults.confspark.executor.memory  1gspark.driver.memory  1gOn a new cluster:Add a configuration object similar to the following when you launch a cluster:[  {    "Classification": "spark-defaults",    "Properties": {      "spark.executor.memory": "1g",      "spark.driver.memory":"1g",    }  }]For a single job:Use the --executor-memory and --driver-memory options to increase memory when you run spark-submit.For example:spark-submit --class org.apache.spark.examples.SparkPi --master yarn --deploy-mode cluster --executor-memory 1g --driver-memory 1g /usr/lib/spark/examples/jars/spark-examples.jar 100Other solution optionsIf you still get the error message, try the following:Benchmarking: It's a best practice to run your application against a sample dataset. Doing so can help you spot slowdowns and skewed partitions that can lead to memory problems.Data filtration: Be sure that you are processing the minimum amount of data. If you don't filter your data, or if you filter late in the application run, then excess data might slow down the application. This can increase the chance of a memory exception.Dataset size: It's a best practice to process the minimum required data. Partition your data so that only the required data is ingested.Partitioning strategy: Consider using a different partitioning strategy. For example, partition on an alternate key to avoid large partitions and skewed partitions.EC2 instance type: It's possible that your EC2 instance doesn't have the memory resources required for your workload. Switching to a larger memory-optimized instance type might resolve the error. If you still get memory exceptions after changing instance types, try the troubleshooting methods on the new instance.Related informationSpark configurationHow do I resolve the "java.lang.ClassNotFoundException" in Spark on Amazon EMR?Follow"


Question: How can I set up cross-account access for Amazon EMRFS?

I want to use the Amazon EMR File System (EMRFS) to write to Amazon Simple Storage Service (Amazon S3) buckets that are in a different AWS account.

Answer: "I want to use the Amazon EMR File System (EMRFS) to write to Amazon Simple Storage Service (Amazon S3) buckets that are in a different AWS account.Short descriptionUse one of the following options to set up cross-account access for EMRFS:Add a bucket policy. Add a bucket policy for the destination bucket that grants access to the Amazon EMR account. This is easiest option. However, the destination account doesn't own the objects that EMRFS writes to the destination bucket.Use a custom credentials provider. This option allows you to assume an AWS Identity and Access Management (IAM) role in the destination bucket account. This means that the destination account owns objects that EMRFS writes to the destination bucket.Use role mappings in a security configuration. This option also allows EMRFS to assume an IAM role in the destination bucket account. This is the method that's discussed in this article.ResolutionWhen you use a security configuration to specify IAM roles for EMRFS, you set up role mappings. A role mapping specifies an IAM role that corresponds to an identifier. An identifier determines the basis for access to Amazon S3 through EMRFS. Identifiers can be users, groups, or Amazon S3 prefixes that indicate a data location. When EMRFS makes a request that matches the basis for access, EMRFS has cluster EC2 instances assume the corresponding IAM role for the request. The IAM permissions attached to that role apply, instead of the IAM permissions attached to the service role for cluster EC2 instances. For more information, see Configure IAM roles for EMRFS requests to Amazon S3.In the following steps, an identifier is specified as an Amazon S3 prefix that is accessed through EMRFS. This creates cross-account access for EMRFS using a security configuration with role mapping:1.    Create an IAM role in the destination account. This is the role that you will assume from the EMR cluster.2.    Add a trust policy similar to the following. The trust policy must allow the Amazon Elastic Compute Cloud (Amazon EC2) role for Amazon EMR to assume the role that you created in step 1. For more information, see Configure roles.{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Principal": {        "AWS": "arn:aws:iam::EMRFSAcctID:role/EMR_EC2_DefaultRole"      },      "Action": "sts:AssumeRole"    }  ]}3.    Use the AWS Command Line Interface (AWS CLI) to create a security configuration with a role mapping. The role mapping must specify the role in the destination account (the role that you created in step 1).Note: You must use the AWS CLI or an SDK to create the security configuration. The console doesn't list roles in other accounts, even if you have permissions to assume those roles. If you receive errors when running AWS CLI commands, make sure that you're using the most recent version of the AWS CLI.Supply a JSON object similar to the following for the role mapping. Replace these values in the example:arn:aws:iam::DestinationAcctID:role/role_in_destination_account: the Amazon Resource Name (ARN) of the role that you created in step 1s3://doc-example-bucket/: the bucket that you want EMRFS to write to{  "AuthorizationConfiguration": {    "EmrFsConfiguration": {      "RoleMappings": [        {          "Role": "arn:aws:iam::DestinationAcctID:role/role_in_destination_account",          "IdentifierType": "Prefix",          "Identifiers": [            "s3://doc-example-bucket/"          ]        }      ]    }  }}4.    Create an IAM policy and then attach it to the Amazon EMR EC2 instance profile (for example, EMR_EC2_DefaultRole).The following example policy allows AWS Security Token Service (STS) to assume all roles. At a minimum, your policy must allow STS to assume the role that you created in step 1. For more information, see Granting permissions to create temporary security credentials.{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Action": "sts:AssumeRole",      "Resource": "*"    }  ]}5.    Launch an EMR cluster and specify the security configuration that you created in step 3.Note: If the destination bucket uses server-side encryption with AWS Key Management Service (AWS KMS), then the assumed role must be a key user in the AWS KMS customer managed key. You can't access the bucket if the role isn't listed in the AWS KMS key.Related informationCreate a security configurationFollow"