Question: Why does my EBS volume fail to attach to my EC2 instance for the first time?

"I attached an existing Amazon Elastic Block Store (Amazon EBS) volume to my Amazon Elastic Compute Cloud (Amazon EC2) instance. But, it failed with a message saying "vol-xxx is already attached to an instance.""

Answer: "I attached an existing Amazon Elastic Block Store (Amazon EBS) volume to my Amazon Elastic Compute Cloud (Amazon EC2) instance. But, it failed with a message saying "vol-xxx is already attached to an instance."Short descriptionSpecific Amazon EC2 instance types require Scalable Reliable Datagram (SRD) to give you the benefit of high Amazon EBS performance. The specific instance types include C6in, C7g, M6in, M6idn, R5b, R6in, R6idn, Trn1, X2idn,and X2iedn. SRD is a reliable, high performance, lower-latency network transport protocol that is designed specifically for AWS.ResolutionWhen you attach an existing Amazon EBS volume to an instance type that requires SRD for the first time, Amazon EBS modifies the volume. Amazon EBS moves it to an SRD-capable infrastructure. There can only be one modification operation on the same volume at a time. If your volume is undergoing a modification during an attempt to attach the volume, the attempt to move the volume to the SRD-capable infrastructure fails.When an existing EBS volume fails to attach to the SRD-capable instance (C6in, C7g, M6in, M6idn, R5b, R6in, R6idn, Trn1, X2idn, and X2iedn), a notification is sent to your account's Personal Health Dashboard (PHD). This notification provides details about the operational activity that is required to move the EBS volume to the SRD-capable infrastructure.Note: R5b.8xlarge is used in the following example.If you initiated the existing modification, then the following notification appears:r5b.8xlarge is an SRD capable instance. In order to give you the benefit of the performance of an r5b.8xlarge instance, we have to move your volume to SRD capable infrastructure via the modifyVolume process. We are unable to perform the modification operation at this time because your volume is already undergoing modification. You can track the progress of the current modification via the describe-volume-modifications API. Once the modification is completed you can attach the volume to the instance r5b.8xlarge. If you urgently need to access data from this volume, please attach it to any instance family other than C6in, C7g, M6in, M6idn, R5b, R6in, R6idn, Trn1, X2idn, and X2iedn.If Amazon EBS initiated the existing modification, then the following notification appears:r5b.8xlarge is an SRD capable instance. In order to give you the benefit of the performance of an r5b.8xlarge instance, we have to move your volume to SRD capable infrastructure via the modifyVolume process. We are unable to perform the modification operation at this time because of an operational activity being performed by EBS on the server hosting your volume. Your volume is in a healthy and fully redundant state. We will send an update as soon as the operational activity is complete. You can then attach the volume to the instance r5b.8xlarge. This operational activity may last for up to 48 hrs. If you urgently need to access data from this volume, please attach it to any instance family other than C6in, C7g, M6in, M6idn, R5b, R6in, R6idn, Trn1, X2idn, and X2iedn.To view your accounts PHD notices, see Your account events.The modification operational activity might last up to 48 hours. You can wait until the original volume modification is complete, then attach the EBS volume to the SRD-capable instance again. If you must access data from your EBS volume, then attach the volume to an instance type other than what's listed in the PHD notification. After modification is complete, attach the EBS volume to your R5b instance.Related informationIn the search for performance, there's more than one way to build a networkAmazon EC2 instance typesFollow"


Question: Why aren't my emails sent using Amazon SES reaching their destination?

"I sent an email using Amazon Simple Email Service (Amazon SES) but I can't find the message in my inbox. Or, I tried sending an email using Amazon SES, but I got an error."

Answer: "I sent an email using Amazon Simple Email Service (Amazon SES) but I can't find the message in my inbox. Or, I tried sending an email using Amazon SES, but I got an error.ResolutionCheck for sending issues within your Amazon SES accountCheck if your sending account is in the Amazon SES sandbox. Then, check if the recipient that you're trying to send the email to is a verified email address or domain. If your sending account is in the sandbox, then you can send emails only to email addresses or domains verified for use with Amazon SES. You can open a request to move your account into production mode. If Amazon SES approves your request, then you can send emails to any recipient.Check if your account's sending ability is paused. If Amazon SES put your account under a sending pause, you must resolve any issues and then request a review of your account.Check for sending issues from the email client to Amazon SESReview your email client for any error messages returned by Amazon SES.If Amazon SES is returning "Maximum sending rate exceeded" or "Daily sending quota exceeded" error messages, then you must review your account's sending rate.If you use an email template (SendTemplatedEmail operation), then check if your template data has variables that are missing or not valid. In either case, Amazon SES can't deliver the email. This is called a Rendering Failure. For more information, see Why are emails failing to deliver when I send Amazon SES emails using the SendTemplatedEmail operation?If you have Simple Mail Transfer Protocol (SMTP) timeout or connectivity issues, then troubleshoot the TCP connection and the SSL/TLS negotiations.Review and debug your email-sending application for any client-side errors that might cause the sending issues. To identify if you might have client-side issues, test your connection to the Amazon SES SMTP endpoint. If your email client can't reach the endpoint, then troubleshoot your network.Check for sending issues from Amazon SES to the recipient domainCheck if your email results in soft bounces or hard bounces from the recipient domain. To do this, set up bounce notifications using Amazon Simple Notification Service (Amazon SNS). Within a bounce notification, review the bounceType and bounceSubType fields to get more information about what caused the bounce.Verify if there's a delay in the delivery of your email. To do so, you can configure Amazon SES event publishing to Amazon CloudWatch, Amazon Kinesis Data Firehose, or Amazon SNS. To set up notifications for delivery delays, you must run the UpdateConfigurationSetEventDestination call using the Amazon SES API V2.Check the bounce notification for an SMTP response with the status code 554 and a message that says the sending IP address is blocked. This means that your email was rejected because the sender IP address is part of an IP blocklist that the recipient email provider uses. Be sure to review the policies for removing Amazon SES IP addresses from IP blocklists. To avoid using a sending IP address that's on an IP blocklist, use dedicated IP addresses so that you have control over the sender reputation.Important: Bounces from issues on the recipient end can still impact your sending account's deliverability rate. As the sender, it's important that you monitor your bounce rate and prevent further bounces. If your account's bounce rate is 5% or greater, then Amazon SES can place your account under review. If your bounce rate is 10% or greater, then Amazon SES might pause your account's ability to send emails.Check for sending issues from the recipient domain to the user's inboxCheck the recipient's spam folder for the email that you sent using Amazon SES. Several factors can lead to a recipient's mail server flagging an email as spam, such as content filters or the lack of email authentication. For more information, see Why are the emails that I send using Amazon SES getting marked as spam?Confirm that your emails follow the guidelines at Complying with DMARC using Amazon SES.Follow"


Question: Why is my Amazon DynamoDB table stuck in the UPDATING status?

"After updating the provisioned capacity for my Amazon DynamoDB table, the table remains in the UPDATING status for a long time."

Answer: "After updating the provisioned capacity for my Amazon DynamoDB table, the table remains in the UPDATING status for a long time.ResolutionWhen you update the provisioned capacity for your DynamoDB table and increase the value to a new peak, DynamoDB changes several things at the backend, such as adding new partitions to the table, to make sure that the table has enough capacity to serve your traffic. If you decrease the provisioned capacity and scale up again to the same peak, the update operation might be faster. Also, your table remains available during the update operation and supports your provisioned throughput requirements. Note that the time taken to update the provisioned capacity for the table depends on several factors, such as the size of the table and the difference between the previous and the new peak.Related informationUpdateTableFollow"


Question: How can I send user-data output to the console logs on an EC2 instance running Amazon Linux or Amazon Linux 2?

I'm trying to troubleshoot my Amazon Elastic Compute Cloud (Amazon EC2) Linux instance bootstrap. How can I log the user-data invocation and then ship it to the console logs?

Answer: "I'm trying to troubleshoot my Amazon Elastic Compute Cloud (Amazon EC2) Linux instance bootstrap. How can I log the user-data invocation and then ship it to the console logs?Short descriptionTo troubleshoot issues on your EC2 instance bootstrap without having to access the instance through SSH, you can add code to your user-data bash script that redirects all the output both to the /var/log/user-data.log and to /dev/console. When the code is run, you can see your user-data invocation logs in your console.Note: This resolution is for Amazon Linux and Amazon Linux 2 only. For information on instances running RHEL 7 or RHEL 8, see How can I log user-data for my EC2 instance running RHEL 7 or RHEL 8 and then ship it to the console logs?ResolutionEnter the following command to redirect the user-data output console:#!/bin/bash -xeexec > >(tee /var/log/user-data.log|logger -t user-data -s 2>/dev/console) 2>&1  yum -y update  echo "Hello from user-data!"The following is the line that redirects the user-data output:exec > >(tee /var/log/user-data.log|logger -t user-data -s 2>/dev/console) 2>&1By default, user data scripts and cloud-init directives are run only during the first boot when an instance is launched. For more information, see How can I utilize user data to automatically run a script with every restart of my Amazon EC2 Linux instance?The following is sample console output:<13>Nov 13 13:49:59 user-data:   amazon-ssm-agent.x86_64 0:2.3.228.0-1.amzn2<13>Nov 13 13:49:59 user-data:   irqbalance.x86_64 2:1.5.0-2.amzn2.0.1<13>Nov 13 13:49:59 user-data:   kernel-tools.x86_64 0:4.14.77-80.57.amzn2<13>Nov 13 13:49:59 user-data:   kmod.x86_64 0:25-3.amzn2.0.2<13>Nov 13 13:49:59 user-data:   kmod-libs.x86_64 0:25-3.amzn2.0.2<13>Nov 13 13:49:59 user-data:   lz4.x86_64 0:1.7.5-2.amzn2.0.1<13>Nov 13 13:49:59 user-data:   nss.x86_64 0:3.36.0-7.amzn2<13>Nov 13 13:49:59 user-data:   nss-sysinit.x86_64 0:3.36.0-7.amzn2<13>Nov 13 13:49:59 user-data:   nss-tools.x86_64 0:3.36.0-7.amzn2<13>Nov 13 13:49:59 user-data:   openssl.x86_64 1:1.0.2k-16.amzn2.0.1<13>Nov 13 13:49:59 user-data:   openssl-libs.x86_64 1:1.0.2k-16.amzn2.0.1<13>Nov 13 13:49:59 user-data:<13>Nov 13 13:49:59 user-data: Complete!<13>Nov 13 13:49:59 user-data: + echo 'Hello from user-data!Note: The posted system (console) log output isn't updated continuously. Instances built on the Nitro system support the retrieval of the latest serial console output. For more information, see Instance console output.Related informationRun commands on your Linux instance at launchFollow"


Question: Why is my EC2 AMI or EBS snapshot creation slow?

"I'm trying to create a backup of my Amazon Elastic Compute Cloud (Amazon EC2) instance or Amazon Elastic Block Store (Amazon EBS) volume by creating an Amazon Machine Image (AMI) or snapshot. However, this process is slow or appears to be stuck in the Pending state."

Answer: "I'm trying to create a backup of my Amazon Elastic Compute Cloud (Amazon EC2) instance or Amazon Elastic Block Store (Amazon EBS) volume by creating an Amazon Machine Image (AMI) or snapshot. However, this process is slow or appears to be stuck in the Pending state.Short descriptionAmazon EBS-backed AMIs include one or more Amazon EBS snapshots. The creation of EBS-backed AMIs or EBS snapshots might be slow because of the large amount of data that must be copied to Amazon Simple Storage Service (Amazon S3). Many factors, such as Write activity on the EBS volume, can impact the creation time. Therefore, creation times for the snapshots might vary widely.ResolutionDirty blocksThe most common cause for slow creation of AMIs or snapshots is the amount of dirty data that must be copied to Amazon S3. This dirty data is measured by the number of blocks. The following factors might result in a large number of dirty blocks:Size of the EBS volumeTime since last snapshotWrite activity on the volumeSnapshots are designed to be incremental. This means that Amazon EBS copies only the blocks that changed since the last snapshot was created. An EBS volume might not have an existing snapshot because no snapshots were created before, or previous snapshots were deleted. In such cases, the blocks can't be compared against any snapshot. Therefore, all the blocks are considered dirty.Also, if a snapshot was created a long time ago, or the EBS volume is very active, you might have a large number of blocks that must be copied as part of the new snapshot.To avoid this issue, it's a best practice to create snapshots frequently. With this practice, the number of blocks to be copied for each snapshot is smaller. You can use Amazon Data Lifecycle Manager to automate the creation, retention, and deletion of snapshots for your EBS volumes. You can set the frequency of snapshots based on your Recovery Point Objective (RPO). EBS snapshots aren't charged based on the number of snapshots, but rather for the incremental data saved in S3. For more information, see Amazon EBS pricing.Multiple volumes queued for snapshot creationSnapshot creation is a shared bandwidth operation. This means that Amazon EBS uses a shared bandwidth to send data to S3. Therefore, you might encounter delays if there are multiple volumes queued for snapshot creation. This typically happens if several snapshots are created at the top of the hour. For example, if you have automated processes to create snapshots exactly at midnight, then the snapshot creation might be delayed.To avoid this issue, it's a best practice to create snapshots at various times past the hour. This practice might help reduce the time taken to create a snapshot. You can use Amazon Data Lifecycle Manager to automatically create snapshots within an hour after the scheduled start time, instead of creating snapshots immediately.Stacked snapshotsWhen you create multiple snapshots for the same volume within a short period of time, then the first snapshot is created, and the other snapshots are moved to the Pending state. The creation of the snapshots in the Pending state doesn't progress until the first snapshot creation is completed. Deleting a snapshot that's in the Pending state doesn't stop the creation process. If you try to delete the snapshot that's in the Pending state, the snapshot is created first before it's deleted.To resolve this issue, avoid creating snapshots when a snapshot creation for a volume is in progress, unless it's required to do so.Related informationMy Amazon EBS snapshots show no progress or receive the error "ConcurrentSnapshotLimitExceeded". How can I resolve this?Follow"


Question: How do I resolve the "error pulling image configuration: error parsing HTTP 403 response body" error in Amazon ECS when pulling a Docker image from Amazon ECR?

"When I pull a Docker image from Amazon Elastic Container Registry (Amazon ECR) in Amazon Elastic Container Service (Amazon ECS), I get the following error message: "error pulling image configuration: error parsing HTTP 403 response body.""

Answer: "When I pull a Docker image from Amazon Elastic Container Registry (Amazon ECR) in Amazon Elastic Container Service (Amazon ECS), I get the following error message: "error pulling image configuration: error parsing HTTP 403 response body."Short descriptionAmazon ECR uses Amazon Simple Storage Service (Amazon S3) to store your image layers. When your containers download images from Amazon ECR, they must access Amazon ECR to get the image manifest and then Amazon S3 to download the image layers. The following is the Amazon Resource Name (ARN) of the Amazon S3 bucket that contains the layers for each Docker image.arn:aws:s3:::prod-region-starport-layer-bucket/*If you use an S3 gateway endpoint in a route table with a policy that restricts access to starport-layer-bucket, then you receive the following error message:error pulling image configuration: error parsing HTTP 403 response body: invalid character '<' looking for beginning of value: "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Error>AccessDenied<Message>Access Denied</Message><RequestId>SAMPLE-REQUEST-ID</RequestId><HostId>SAMPLE-HOST-ID</HostId></Error>"By default, you get full access to all resources when you create a gateway endpoint in Amazon S3.If you have a custom policy that allows access to specific resources, then you must add the starport-layer-bucket ARN to your Amazon S3 policy to resolve the error.Resolution1.    Open the Amazon Virtual Private Cloud (Amazon VPC) console.2.    From the navigation menu, choose Endpoints.3.    Select the S3 endpoint from the list.4.    Choose the Policy tab, and then choose Edit policy.5.    In the Resource section of the policy, add the following ARN:arn:aws:s3:::prod-region-starport-layer-bucket/*Note: Be sure that the ARN includes your AWS Region.For reference, consider the following example policy:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "Access-to-specific-buckets",      "Effect": "Allow",      "Principal": "*",      "Action": "s3:*",      "Resource": [        "arn:aws:s3:::prod-us-east-1-starport-layer-bucket/*"      ]    }  ]}Related informationCreate the Amazon S3 gateway endpointFollow"


Question: "How do I create, delete, or restore a default VPC in Amazon VPC?"

I want to use a default VPC in Amazon Virtual Private Cloud (Amazon VPC).

Answer: "I want to use a default VPC in Amazon Virtual Private Cloud (Amazon VPC).Short descriptionEach AWS Region in your AWS account is provided a default VPC. You can use the default VPC instead of creating and configuring your own VPC. The default VPC is available for immediate use to launch AWS services, such as Amazon Elastic Compute Cloud (Amazon EC2) instances.ResolutionCan I create a new default VPC?If you don't want to use the default VPC, then you can create a new one. Use either the Amazon VPC console or AWS Command Line Interface (AWS CLI) to create the new default VPC. For more information, see Create a default VPC.Can I delete a default VPC?If you delete a default VPC, subnets, and internet gateway, then there isn't a direct impact on your other AWS resources in non-default VPCs. Depending on your network architecture configuration, there might be traffic impact. For example, there might be impact to VPC peering or transit gateway attachments for your default VPC. However, if you don't have AWS resources that carry production traffic in your default VPC, then there's no impact.If you delete your default VPC, then you must launch resources in other VPCs. Without a default VPC or subnets, you must specify the VPC and subnet IDs when launching EC2 instance and other resources.Important: If you delete your default subnets or default VPC, then you must explicitly specify a subnet in another VPC to launch your instance into.Before deleting your VPC, review the default VPC components.In your manually created VPC, make sure that all items are working correctly.For the default VPC that you want to delete, verify that it doesn't have any resources or running services. After you delete the VPC, services or resources on the default VPC are no longer available.Can I make an existing VPC the default VPC or restore a deleted default VPC in Amazon VPC?You can't select an existing non-default VPC as your new default VPC. You also can't restore a previous default VPC that you deleted.How do I delete a default VPC?For information on how to delete a VPC, see Delete your VPC.Related informationDefault VPCsFollow"


Question: How can I troubleshoot connectivity issues when using NAT gateway on my private VPC?

I'm using a NAT gateway to connect instances in a private Virtual Private Cloud (Amazon VPC) subnet to the internet. The instances have intermittent connection issues. How can I troubleshoot this?

Answer: "I'm using a NAT gateway to connect instances in a private Virtual Private Cloud (Amazon VPC) subnet to the internet. The instances have intermittent connection issues. How can I troubleshoot this?Short descriptionPrivate subnet resources might experience intermittent connectivity time out issues for the following reasons:Network access control list (ACL) rules.ErrorPortAllocation error on the NAT gateway.Client instance port exhaustion.Private subnet resources might experience a sudden connection drop for the following reason:IdleTimeoutCount error to release capacity.Private subnet resources might experience slowness for the following reason:Bandwidth limitation per NAT gateway.ResolutionPrivate subnet resources are experiencing intermittent connectivity time out issuesNetwork ACL rulesConfirm that the network ACL associated to the public subnet where the NAT gateway is present allows traffic from the ephemeral port range (1024-65535). If the network ACL allows only a subset of the ephemeral port range and the instances in the private subnet use a source port outside of that range, then traffic is dropped. For more information on how to configure network ACLs, see Recommended network ACL rules for a VPC with public and private subnets (NAT).ErrorPortAllocation error on the NAT gatewayFor more information on this error, see How do I resolve the ErrorPortAllocation error on my NAT gateway?Client instance port exhaustionCheck if the client instances in the private subnet have reached their operating system-level connection limits. To see the number of active connections, run the netstat command:Linux:netstat -ano | grep ESTABLISHED | wc --lnetstat -ano | grep TIME_WAIT | wc --lWindows:netstat -ano | find /i "estab" /cnetstat -ano | find /i "TIME_WAIT" /cIf the preceding command returns a value near the allowed local port range (the source port for client connections), then you might have port exhaustion.To reduce port exhaustion, do the following:Resolve any application-level issues that drain the available connections.Increase the operating system local (ephemeral) port range by running the following command:net.ipv4.ip_local_port_range = 1025 61000Private subnet resources are experiencing sudden connection dropsIdleTimeoutCount error to release capacityIf a connection that's using a NAT gateway is idle for 350 seconds or more, then the connection times out and you see a spike on the IdleTimeoutCount metric. When a connection times out, a NAT gateway returns an RST packet to any resources behind the NAT gateway that attempts to continue the connection. The NAT gateway doesn't send a FIN packet.Workaround for the IdleTimeoutCount error:Use the IdleTimeoutCount metric in Amazon CloudWatch to monitor for increases in idle connections. Configure CloudWatch Contributor Insights to get visibility on the top contributors of clients with processes in the Idle state.Close idle connections from clients to release capacity.Initiate more traffic over the connection.Turn on TCP keepalive on the instance with a value less than 350 seconds.Private subnet resources are experiencing slownessBandwidth limitations on the NAT gatewayA NAT gateway supports 5 Gbps of bandwidth and automatically scales up to 45 Gbps. If the combined sum of networking throughput metrics across all the instances behind the NAT gateway is equal to or more than 45 Gbps bursts, the traffic slows.Using CloudWatch metrics, bandwidth is calculated as: (BytesOutToDestination + BytesOutToSource + BytesInFromDestination + BytesInFromSource) * 8 / time period in seconds.Workaround for bandwidth limitations per NAT gateway:If your bandwidth on the NAT gateway is greater than 45 Gbps, you can split the resources between multiple subnets and create multiple NAT gateways.Related informationHow can I use Amazon CloudWatch metrics to identify NAT gateway bandwidth issues?How do I resolve intermittent connection issues when using a NAT instance?Follow"


Question: Why can't I connect to my Amazon EKS cluster?

"I created an Amazon Elastic Kubernetes Service (Amazon EKS) cluster, but I can't connect to my cluster."

Answer: "I created an Amazon Elastic Kubernetes Service (Amazon EKS) cluster, but I can't connect to my cluster.Short descriptionYou might not be able to connect to your EKS cluster because of one of the following reasons:You didn't create the kubeconfig file for your cluster.You are unable to connect to the Amazon EKS API server endpoint.ResolutionYou didn't create the kubeconfig fileAfter you create your Amazon EKS cluster, you must configure yourkubeconfig file using the AWS Command Line Interface (AWS CLI). This configuration allows you to connect to your cluster using thekubectl command line. The following resolution shows you how to create a kubeconfig file for your cluster with the AWS CLIupdate-kubeconfig command. To manually update your kubeconfig file without using the AWS CLI, seeCreating or updating a kubeconfig file for an Amazon EKS cluster.Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent AWS CLI version.1.    Verify that the AWS CLI version 1.16.308 or later is installed on your system:$ aws --versionImportant: You must have Python version 2.7.9 or later installed on your system. Otherwise, you receive an error.Tip: Use package managers such as yum, apt-get, or homebrew for macOS to install the AWS CLI.2.    Check the current identity to verify that you're using the correct credentials that have permissions for the Amazon EKS cluster:aws sts get-caller-identityNote: The AWS Identity and Access Management (IAM) entity user or role that creates an Amazon cluster is automatically granted permissions when the cluster is created. These permissions are granted in the cluster's RBAC configuration in the control plane. IAM users or roles can also be granted access to an Amazon EKS cluster in aws-auth ConfigMap. By default, the AWS IAM Authenticator for Kubernetes uses the configured AWS CLI or AWS SDK identity. For more information, see Turning on IAM user and role access to your cluster.3.    Create or update the kubeconfig file for your cluster:aws eks --region example_region update-kubeconfig --name cluster_nameNote: Replace example_region with the name of your AWS Region. Replace cluster_name with your EKS cluster name.By default, the configuration file for Linux is created at the kubeconfig path ($HOME/.kube/config) in your home directory. The file might also be merged with an existing kubeconfig at that location. For Windows, the file is at %USERPROFILE%.kube\config.You can also specify another path by setting the KUBECONFIG (from the Kubernetes website) environment variable, or with the following --kubeconfig option:$ kubectl get pods --kubeconfig ./.kube/configNote: For authentication when running kubectl commands, you can specify an IAM role Amazon Resource Name (ARN) with the --role-arn option. Otherwise, the IAM entity in your default AWS CLI or AWS SDK credential chain is used. For more information, see update-kubeconfig. Or, complete Step 6 in the Create kubeconfig file manually section of Creating or updating a kubeconfig file for an Amazon EKS cluster.4.    Test your configuration:$ kubectl get svcExample output:NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGEsvc/kubernetes   ClusterIP   10.100.0.1   <none>        443/TCP   1mNote: If you receive other authorization or resource type errors, see Unauthorized or access denied (kubectl).You can't connect to the Amazon EKS API server endpoint1.    Verify that you're connecting to the correct Amazon EKS API server URL. To do so, turn on kubectl verbosity, and then run the following command:$ kubectl get svc --v=9The output looks similar to the following:I0110 16:43:36.920095   48173 loader.go:373] Config loaded from file:  /Users/abs/.kube/configI0110 16:43:36.936844   48173 round_trippers.go:466] curl -v -XGET  -H "Accept: application/json;as=Table;v=v1;g=meta.k8s.io,application/json;as=Table;v=v1beta1;g=meta.k8s.io,application/json" -H "User-Agent: kubectl/v1.26.0 (darwin/arm64) kubernetes/b46a3f8" 'https://S123GBNS3HJUFN467UFGH6782JHCH2891.yl4.us-east-2.eks.amazonaws.com//api/v1/namespaces/default/services?limit=500'I0110 16:43:37.362185   48173 round_trippers.go:495] HTTP Trace: DNS Lookup for S123GBNS3HJUFN467UFGH6782JHCH2891.yl4.us-east-2.eks.amazonaws.com/ resolved to [{18.119.155.77 } {3.136.153.3 }]I0110 16:43:37.402538   48173 round_trippers.go:510] HTTP Trace: Dial to tcp:18.119.155.77:443 succeedI0110 16:43:37.500276   48173 round_trippers.go:553] GET https://S123GBNS3HJUFN467UFGH6782JHCH2891.yl4.us-east-2.eks.amazonaws.com//api/v1/namespaces/default/services?limit=500 200 OK in 563 millisecondsI0110 16:43:37.500302   48173 round_trippers.go:570] HTTP Statistics: DNSLookup 1 ms Dial 40 ms TLSHandshake 44 ms ServerProcessing 52 ms Duration 563 msI0110 16:43:37.500308   48173 round_trippers.go:577] Response Headers:I0110 16:43:37.500316   48173 round_trippers.go:580] Audit-Id: 37c17136-7fa7-40e9-8fe6-b24426e81564I0110 16:43:37.500323   48173 round_trippers.go:580] Cache-Control: no-cache, privateI0110 16:43:37.500329   48173 round_trippers.go:580] Content-Type: application/jsonI0110 16:43:37.500334   48173 round_trippers.go:580] X-Kubernetes-Pf-Flowschema-Uid: 508eb99e-d99b-44db-8ade-838c99fe8e9fI0110 16:43:37.500340   48173 round_trippers.go:580] X-Kubernetes-Pf-Prioritylevel-Uid: d324d3db-05ce-441b-a0ff-c31cbe8f696cI0110 16:43:37.500345   48173 round_trippers.go:580] Date: Tue, 10 Jan 2023 21:43:37 GMT2.    Verify that the Amazon EKS API server is accessible publicly by running the following command:$ aws eks describe-cluster --name cluster_name --region example_region --query cluster.resourcesVpcConfigThe output looks similar to the following:{    "subnetIds": [        "subnet-abc1",        "subnet-abc2",        "subnet-abc3",        "subnet-abc4",        "subnet-abc5",        "subnet-abc6"    ],    "securityGroupIds": [       "sg-abc7"    ],    "clusterSecurityGroupId": "sg-abc7",    "vpcId": "vpc-abc9",    "endpointPublicAccess": true,    "endpointPrivateAccess": false,    "publicAccessCidrs": [        "0.0.0.0/0"    ]}3.    In the preceding output, ifendpointPublicAccess istrue, then be sure that you allowlist all the source IP addresses in thepublicAccessCidrs list. To do so, do the following:Open the Amazon EKS console.Choose the cluster that you want to update.Choose the Networking tab, and then choose Manage Networking.Select Public.Under Advanced settings, for CIDR block, enter all the public CIDR range that needs to be allowlisted.Choose Save changes.In the preceding output, if endPointPrivateAccess is true, then be sure that the kubectl request is coming from within the cluster's network. If your kubectl request is from outside of your Amazon Virtual Private Cloud (Amazon VPC), then you get the following timeout error:$ kubectl get svc --v=9I0110 17:15:58.889798   50514 loader.go:373] Config loaded from file:  /Users/example-user/.kube/configI0110 17:15:58.896715   50514 round_trippers.go:466] curl -v -XGET  -H "Accept: application/json;as=Table;v=v1;g=meta.k8s.io,application/json;as=Table;v=v1beta1;g=meta.k8s.io,application/json" -H "User-Agent: kubectl/v1.26.0 (darwin/arm64) kubernetes/b46a3f8" 'https://S123GBNS3HJUFN467UFGH6782JHCH2891.yl4.us-east-2.eks.amazonaws.com/api/v1/namespaces/default/services?limit=500'I0110 17:15:59.374499   50514 round_trippers.go:495] HTTP Trace: DNS Lookup for S123GBNS3HJUFN467UFGH6782JHCH2891.yl4.us-east-2.eks.amazonaws.com resolved to [{192.168.126.17 } {192.168.144.26 }]I0110 17:16:14.285027   50514 round_trippers.go:508] HTTP Trace: Dial to tcp:192.168.126.17:443 failed: dial tcp 192.168.126.17:443: i/o timeoutI0110 17:16:29.191768   50514 round_trippers.go:508] HTTP Trace: Dial to tcp:192.168.144.26:443 failed: dial tcp 192.168.144.26:443: i/o timeoutI0110 17:16:29.196959   50514 round_trippers.go:553] GET https://S123GBNS3HJUFN467UFGH6782JHCH2891.yl4.us-east-2.eks.amazonaws.com/api/v1/namespaces/default/services?limit=500  in 30300 millisecondsI0110 17:16:29.197724   50514 round_trippers.go:570] HTTP Statistics: DNSLookup 183 ms Dial 14906 ms TLSHandshake 0 ms Duration 30300 msI0110 17:16:29.197768   50514 round_trippers.go:577] Response Headers:I0110 17:16:29.199254   50514 helpers.go:264] Connection error: Get https://S123GBNS3HJUFN467UFGH6782JHCH2891.yl4.us-east-2.eks.amazonaws.com/api/v1/namespaces/default/services?limit=500: dial tcp 192.168.126.17:443: i/o timeoutUnable to connect to the server: dial tcp 192.168.126.17:443: i/o timeoutAlso, update the cluster security group to make sure that the source IP or CIDR range is allowlisted. This allows the kubectl client to connect to the Amazon EKS API server endpoint.Related informationAmazon EKS troubleshootingHow do I resolve the error "You must be logged in to the server (Unauthorized)" when I connect to the Amazon EKS API server?Follow"


Question: Why are IAM users from another AWS account getting Access Denied errors even though my bucket policy grants full access to that account?

"The policy of my Amazon Simple Storage Service (Amazon S3) bucket grants full access to another AWS account. However, when AWS Identity and Access Management (IAM) users from that account try to access my bucket, they get an Access Denied error."

Answer: "The policy of my Amazon Simple Storage Service (Amazon S3) bucket grants full access to another AWS account. However, when AWS Identity and Access Management (IAM) users from that account try to access my bucket, they get an Access Denied error.Short descriptionIf your bucket policy already grants access to the other account, then cross-account users can get Access Denied errors for these reasons:The user's IAM policy doesn't grant access to the bucket.The object is encrypted by AWS Key Management Service (AWS KMS), and the user doesn't have access to the AWS KMS key.A deny statement in the bucket policy or IAM policy is blocking the user's access.The Amazon Virtual Private Cloud (Amazon VPC) endpoint policy is blocking access to the bucket.The AWS Organizations service control policy is blocking access to the bucket.The object doesn't belong to the AWS account that owns the bucket.You turned on Requester Pays for the bucket.You passed a session policy that's blocking access to the bucket.ResolutionNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you're using the most recent version.The user's IAM policy doesn't grant access to the bucketFor cross-account access, make sure that you grant bucket access in the IAM policy in Account A and the bucket policy in Account B.Follow these steps to check the user's IAM policy in Account A:1.    Open the IAM console.2.    From the console, open the IAM user or role that can't access the bucket.3.    In the Permissions tab of the IAM user or role, expand each policy to view its JSON policy document.4.    In the JSON policy documents, look for policies with the bucket's name. Then, confirm that those policies allow the correct S3 actions on the bucket.5.    If the IAM user or role doesn't grant access to the bucket, then add a policy that grants the correct permissions. For example, the following IAM policy grants a user access to download objects (s3:GetObject) from DOC-EXAMPLE-BUCKET:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "ExampleStmt",      "Action": "s3:GetObject",      "Effect": "Allow",      "Resource": [        "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"      ]    }  ]}The object is encrypted by AWS KMS, and the user doesn't have access to the AWS KMS keyIf both the IAM policy (Account A) and bucket policy (Account B) grant cross-account access, then check the bucket for default encryption with AWS KMS. Or, check the object's properties for AWS KMS encryption. If an object is encrypted by an AWS KMS key, then the user must also have permissions to use the key.To grant an IAM user the permissions to download and upload to a bucket when using a KMS key for encryption, follow these steps:1.    Edit the KMS key policy to add a statement similar to the following one:Note: Enter the IAM user's Amazon Resource Name (ARN) as the Principal.{  "Sid": "ExampleStmt",  "Action": [    "kms:Decrypt",    "kms:GenerateDataKey"  ],  "Effect": "Allow",  "Principal": {    "AWS": "arn:aws:iam::111122223333:user/Jane"  },  "Resource": "*"}2.    If the KMS key belongs to the same account as the IAM user, then you don't need to update the key policy. If the KMS key belongs to a different account than the IAM user, then you must also update the IAM user's permissions. Add an IAM policy statement similar to the following one:Note: Enter the KMS key's ARN as the Resource.{  "Sid": "KMSAccess",  "Action": [    "kms:Decrypt",    "kms:GenerateDataKey"  ],  "Effect": "Allow",  "Resource": "arn:aws:kms:example-region-1:123456789098:key/111aa2bb-333c-4d44-5555-a111bb2c33dd"}A deny statement in the bucket policy or IAM policy is blocking the user's accessCheck the bucket policy and the user's IAM policies for any statements that explicitly deny the user's access to the bucket.Follow these steps to check the bucket policy:1.    Open the Amazon S3 console.2.    From the list of buckets, open the bucket with the bucket policy that you want to check.3.    Choose the Permissions tab.4.    Choose Bucket policy.5.    Look for statements with "Effect": "Deny".6.    Modify the bucket policy to edit or remove any "Effect": "Deny" statements that are denying the user's access to the bucket.Follow these steps to check the user's IAM policies:1.    Open the IAM console.2.    From the console, open the IAM user or role that can't access the bucket.3.    In the Permissions tab of the IAM user or role, expand each policy to view the JSON policy documents.4.    In the JSON policy documents, look for policies related to the S3 bucket with statements that contain "Effect": "Deny".5.    Modify the user's IAM permissions policies to edit or remove "Effect": "Deny" statements that incorrectly deny the user's access to the bucket.The VPC endpoint policy is blocking access to the bucketIf users access the bucket with an Amazon Elastic Compute Cloud (Amazon EC2) instance that's routed through a VPC endpoint, then check the VPC endpoint policy. Confirm that the VPC endpoint policy includes the correct permissions to access the S3 bucket.For example, the following VPC endpoint policy allows access to DOC-EXAMPLE-BUCKET:{  "Id": "Policy1234567890123",  "Version": "2012-10-17",  "Statement": [    {      "Sid": "Stmt1234567890123",      "Action": [        "s3:GetObject",        "s3:PutObject"      ],      "Effect": "Allow",      "Resource": [        "arn:aws:s3:::DOC-EXAMPLE-BUCKET",        "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"      ],      "Principal": "*"    }  ]}Warning: The element "Principal": "*" grants everyone that uses the VPC endpoint access to the bucket. Make sure to restrict the scope of the Principal value as appropriate for your use case.The AWS Organizations service control policy is blocking access to the bucketIf the user's account has turned on AWS Organizations, then check the service control policies to be sure that access to Amazon S3 is allowed. For example, the following policy explicitly denies access to Amazon S3 and results in an Access Denied error:{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Deny",      "Action": "s3:*",      "Resource": "*"    }  ]}For more information on the features of AWS Organizations, see Turning on all features in your organization.The object doesn't belong to the AWS account that owns the bucketBy default, an S3 object is owned by the AWS account that uploaded it. This is true even when the bucket is owned by another account. The bucket's permissions don't automatically apply to an object when the object is owned by a different account.To resolve Access Denied errors from object ownership, try the following solutions:It's a best practice to turn off access control lists (ACLs) for your Amazon S3 buckets. To turn off ACLs, apply the bucket owner enforced setting for S3 Object Ownership. When you apply this setting, you own all the objects in your bucket and have full control over them.To enforce object ownership for new objects without turning off ACLs, apply the bucket owner preferred setting. When applying this setting, it's a best practice to update your bucket policy to require the bucket-owner-full-control canned ACL for all PUT requests to your bucket. The object owner can grant access to the bucket owner with a put-object-acl command:$ aws s3api put-object-acl --bucket examplebucket --key keyname --acl bucket-owner-full-controlNote: To access the object, the object owner must explicitly grant access to the bucket owner. Therefore, use the object owner account to run these commands.You turned on Requester Pays for the bucketIf you turned on Requester Pays for your bucket, then users from other accounts must specify the request-payer parameter when sending requests to your bucket. Otherwise, those users get an Access Denied error.To resolve this error, take the following actions:For DELETE, GET, HEAD, POST, and PUT requests, include x-amz-request-payer : requester in the header.For signed URLs, include x-amz-request-payer=requester in the request.For AWS CLI commands, include the --request-payer parameter. Example:$ aws s3 cp exampleobject.jpg s3://DOC-EXAMPLE-BUCKET/exampleobject.jpg --request-payer requesterYou passed a session policy that's blocking access to the bucketA session policy is an inline policy that you can quickly create and pass in the session during role assumption. You can pass the session policy to further scope the permissions of the role session. Session policies are advanced policies that you pass as a parameter when you programmatically create a temporary session for a role or federated user. The effective permissions of the session are the intersection of the role’s identity-based policies and the session policy. Therefore, make sure that the session policy that you passed isn't blocking access to the S3 bucket.Related informationHow do I troubleshoot 403 Access Denied errors from Amazon S3?Why are cross-account users getting Access Denied errors when they try to access my bucket that's encrypted by a custom AWS KMS key?Follow"


Question: How can I receive SNS notifications about Amazon RDS for SQL Server error and agent log events that match a CloudWatch filter pattern?

I have an Amazon Relational Database Service (Amazon RDS) DB instance that runs SQL Server. I want to create Amazon CloudWatch alarms and Amazon Simple Notification Service (Amazon SNS) topics so that I'm notified about SQL Server error and agent log events that match specific CloudWatch filter patterns. How can I do this?

Answer: "I have an Amazon Relational Database Service (Amazon RDS) DB instance that runs SQL Server. I want to create Amazon CloudWatch alarms and Amazon Simple Notification Service (Amazon SNS) topics so that I'm notified about SQL Server error and agent log events that match specific CloudWatch filter patterns. How can I do this?Short descriptionFirst, publish SQL Server logs to Amazon CloudWatch Logs. Then, create CloudWatch alarms and SNS notifications for the SQL Server DB log events that match the filter pattern that you create.After the Amazon RDS for SQL Server log data is published to CloudWatch, you can create metric filters to search and filter the logs. Metric filters define the terms and patterns that are searched for in the log data as it is sent to Amazon CloudWatch Logs. Then, CloudWatch Logs uses the metric filters to turn log data into numerical CloudWatch metrics that you can set alarms for. You can use any type of CloudWatch statistic, including percentile statistics, when viewing these metrics or setting alarms. For more information, see Creating metrics from log events using filters.ResolutionYou can create filter patterns, such as "Login failed for user" to identify failed login attempts. Or, you can create a filter for "I/O requests taking longer than 15 seconds to complete" to identify I/O bottlenecks or disk bottlenecks.The following example uses a metric filter to search for and count events that include the term "Login failed for user" to track failed login attempts.Open the Amazon RDS console, and choose Databases from the navigation pane.Choose the name of the DB instance that you want to configure CloudWatch metrics for.From the Configuration tab, choose Error under CloudWatch Logs. This opens the Logs pane in the CloudWatch console. If you don't see a Published Logs section, be sure that you are publishing for SQL Server logs to CloudWatch Logs.From the CloudWatch console navigation pane, choose Log groups.Choose the error log for the RDS DB instance, and then choose Create Metric Filter.For Filter Pattern, enter a pattern, such as "Login failed for user."Note: All entries in the filter pattern are case sensitive.From the same page, you can test the filter pattern. Select the log group that you want to test the filter against under the Select Log Data to Test section, and then choose Test Pattern.From the Results section, you can see how many results match the filter pattern in the log file. You can also choose Show test results to see more details.Choose Assign Metric.Enter a Filter name and a Metric name.Choose Show advanced metric settings, and confirm that Metric Value is set to 1. This value specifies that the count is incremented by 1 for each log event that contains "Login Failed for User."For Default Value, enter 0.Choose Create Filter. A Create Alarm button displays. Choose Create Alarm.From the Period dropdown list, select the evaluation period. The default period is 5 minutes.From the Conditions section, choose the following:Threshold type - Static.Whenever test is - Greater > threshold.Than - Enter 10.Expand the Additional configuration section. For Datapoints to alarm, enter the number of evaluation periods (data points) that must be in the ALARM state to trigger the alarm.From Missing data treatment, select Treat missing data as missing.Choose Next.From the Notification section, under Select an SNS topic, select an existing SNS topic, or create a new topic to receive notifications.Enter the email endpoints that you want to receive the notification.Choose Next.Enter the Alarm name and Alarm description, and then choose Next.From the Preview and create page, review the Metric graph and Conditions.Choose Create alarm.After following these example steps, the alarm state is Insufficient data for the first few minutes. After the alarm has enough data, the status is OK. If you receive more than 10 login failures within a 5-minute period, then the CloudWatch alarm sends an SNS notification to the email that you specified.Related informationOverview of monitoring metrics in Amazon RDSFollow"


Question: How can I resolve the error I get when my EC2 instances fail to communicate with Elastic Beanstalk?

"When I try to create an AWS Elastic Beanstalk environment, I get the error: "The EC2 instances failed to communicate with AWS Elastic Beanstalk, either because of configuration problems with the VPC or a failed EC2 instance. Check your VPC configuration and try launching the environment again.""

Answer: "When I try to create an AWS Elastic Beanstalk environment, I get the error: "The EC2 instances failed to communicate with AWS Elastic Beanstalk, either because of configuration problems with the VPC or a failed EC2 instance. Check your VPC configuration and try launching the environment again."Short descriptionAmazon Elastic Compute Cloud (Amazon EC2) instances must be configured to initiate outbound connections to Elastic Beanstalk and other service endpoints. To avoid the failed to communicate error, your EC2 instances must be configured to initiate outbound connections through one of the following:Public subnet (Internet Gateway)Private subnet (Nat Gateway)VPC endpointsResolutionVerify that the network ACL associated with your subnets allows outbound connections to the internet. For example: 0.0.0.0/0.If you select a custom Amazon Virtual Private Cloud (Amazon VPC) when you create your Elastic Beanstalk environment, then choose the appropriate subnets. The subnets must allow for instance and load balancer visibility.If your EC2 instances are in a public subnet, then verify that the route table has a route to the internet through an internet gateway. For example: 0.0.0.0/0.Verify that the public subnet has "auto-assign public IPv4 address" turned on in the VPC subnets console. The VPC subnets console must display Auto-assign public IPv4 address: Yes.If your EC2 instances are in a private subnet, then verify that the route table associated with the NAT gateway or the NAT instance has a route to the internet. For example: 0.0.0.0/0.Note: Your NAT gateway or NAT instance must be created in a public subnet to communicate with the internet.Verify that the VPC attributes enableDnsHostnames and enableDnsSupport are turned on in the VPC where you launched your environment.If your Elastic Beanstalk environment is using VPC endpoints, then set up the following endpoints to launch your environment properly:Amazon Simple Queue Service (Amazon SQS)AWS CloudFormationElastic Beanstalk (elasticbeanstalk.region.amazonaws.com)Elastic Beanstalk Health (elasticbeanstalk-health.region.amazonaws.com)Amazon Simple Storage Service (Amazon S3) Gateway endpointNote: If your environment must interact with other AWS services, then create the appropriate VPC endpoints for those services.If you're using a custom AMI other than the Elastic Beanstalk-provided AMI, then make sure that you create the AMI so that EC2 instances can reach the internet.Related informationWhy can't my EC2 instance in a private subnet connect to the internet using a NAT gateway?Route tables for your VPCFollow"


Question: Why is IPsec/Phase 2 for AWS Site-to-Site VPN failing to establish a connection?

"When I try to set up an AWS Site-to-Site VPN connection in Amazon Virtual Private Cloud (Amazon VPC), the IPsec/Phase 2 of my configuration fails to establish a connection."

Answer: "When I try to set up an AWS Site-to-Site VPN connection in Amazon Virtual Private Cloud (Amazon VPC), the IPsec/Phase 2 of my configuration fails to establish a connection.ResolutionIf your Site-to-Site VPN Internet Protocol security (IPsec/Phase 2) fails to establish a connection, then try the following steps to resolve the problem:Verify that the Site-to-Site VPN Phase 2 parameters are configured correctly on your customer gateway device. To do so, compare your settings against the VPN configuration file that you downloaded from the Site-to-Site VPN console.Verify that the supported Phase 2 parameters for IKEv1 and IKEv2 are configured correctly:Example IKEv1 and IKEv2 parameters:IKEv1 Encryption: AES-128, AES-256, AES128-GCM-16, AES256-GCM-16IKEv1 Data Integrity: SHA-1, SHA2-256, SHA2-384, SHA2-512IKEv1 DH groups: 2, 5, and 14-24Lifetime: 3600 secondsDiffie-Hellman Perfect Forward Secrecy: EnabledNote: The example IKEv1 and IKEv2 Phase 2 and IKEv2 Child_SA parameters specify the minimum requirements for a Site-to-Site VPN connection of:AWS Phase 2 parameters: AES128, SHA1, Diffie-Hellman group 2AWS GovCloud (US) Phase 2 parameters: AES128, SHA2, Diffie-Hellman group 14Verify that Diffie-Hellman Perfect Forward Secrecy (PFS) is active and is using Diffie-Hellman groups for key generation. For more information, see the Use Diffie-Hellman Perfect Forward Secrecy section.Verify that there is no security association or traffic selector mismatch between AWS and the customer gateway device.Verify whether the configured Site-to-Site VPN connection options, including remote and local IP addresses, match the security association specified on the customer gateway device. For more information, see How do I troubleshoot connection problems between an AWS VPN endpoint and a policy-based VPN?Verify if traffic is initiated inbound towards AWS. Site-to-Site VPN works in responder mode by default, allowing configuration changes to IKE negotiations, peer timeout settings, and other configuration settings. For more information, see Site-to-Site VPN tunnel initiation options.If your issue still persists, try the following:Turn on Site-to-Site VPN logs.Examine the IPsec debug logs to learn the cause of the failure and troubleshooting steps.Related informationExample customer gateway device configurations for dynamic routing (BGP)Example customer gateway device configurations for static routingModifying Site-to-Site VPN tunnel optionsWhat is AWS Site-to-Site VPN?Follow"


Question: How can I optimize performance when I upload large files to Amazon S3?

I want to upload large files (1 GB or larger) to Amazon Simple Storage Service (Amazon S3). How can I optimize the performance of this upload?

Answer: "I want to upload large files (1 GB or larger) to Amazon Simple Storage Service (Amazon S3). How can I optimize the performance of this upload?Short descriptionWhen you upload large files to Amazon S3, it's a best practice to leverage multipart uploads. If you're using the AWS Command Line Interface (AWS CLI), then all high-level aws s3 commands automatically perform a multipart upload when the object is large. These high-level commands include aws s3 cp and aws s3 sync.Consider the following options for improving the performance of uploads and optimizing multipart uploads:If you're using the AWS CLI, customize the upload configurations.Enable Amazon S3 Transfer Acceleration.ResolutionIf you're using the AWS CLI, customize the upload configurationsYou can customize the following AWS CLI configurations for Amazon S3:max_concurrent_requests: This value sets the number of requests that can be sent to Amazon S3 at a time. The default value is 10.Note: Running more threads consumes more resources on your machine. You must be sure that your machine has enough resources to support the maximum number of concurrent requests that you want.max_queue_size: This value sets the maximum number of tasks in the queue. The default value is 1,000.multipart_threshold: This value sets the size threshold for multipart uploads of individual files. The default value is 8 MB.multipart_chunksize: This value sets the size of each part that the AWS CLI uploads in a multipart upload for an individual file. This setting allows you to break down a larger file (for example, 300 MB) into smaller parts for quicker upload speeds. The default value is 8 MB.Note: A multipart upload requires that a single file is uploaded in not more than 10,000 distinct parts. You must be sure that the chunksize that you set balances the part file size and the number of parts.max_bandwidth: This value sets the maximum bandwidth for uploading data to Amazon S3. There is no default value.Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.Enable Amazon S3 Transfer AccelerationAmazon S3 Transfer Acceleration can provide fast and secure transfers over long distances between your client and Amazon S3. Transfer Acceleration uses Amazon CloudFront's globally distributed edge locations.Transfer Acceleration incurs additional charges, so be sure to review pricing. To determine if Transfer Acceleration might improve the transfer speeds for your use case, review the Amazon S3 Transfer Acceleration Speed Comparison tool.Note: Transfer Acceleration doesn't support cross-Region copies using CopyObject.Follow"


Question: How do I choose the right primary key for my Amazon DynamoDB table?

I want to know the considerations when choosing a primary key for my Amazon DynamoDB table.

Answer: "I want to know the considerations when choosing a primary key for my Amazon DynamoDB table.Short descriptionThere are two types of primary keys in DynamoDB:Partition key: This is a simple primary key. If the table has only a partition key, then no two items can have the same partition key value.Composite primary key: This is a combination of partition key and sort key. If the table has a composite primary key, then two items might have the same partition key value. However, those items must have different sort key values.The primary key must be unique for each item in the table irrespective of the type of primary key that you choose. Failure to choose an appropriate primary key might lead to uneven data distribution and hot keys that might cause throttling (ProvisionedThroughputExceededException).ResolutionUse one or more of the following strategies when choosing a primary key:Use a high-cardinality attribute: The partition key must be an attribute that has unique values for each item, such as user ID, email, or phone number.Use composite attributes: Combine multiple attributes to form a primary key. For example, you might have an "orders" table that combines the customer ID, product ID, and country code for the partition key, and then uses the order date as the sort key. This increases the likelihood that each item has a unique primary key.Add random numbers to your partition key: For write-heavy use cases, consider adding random numbers from a predetermined range to your partition key. This increase the randomness of the partition key. For more information, see Using write sharding to distribute workloads evenly.For detailed information about each of these strategies, see Choosing the right DynamoDB partition key.Related informationBest practices for designing and using partition keys effectivelyWhy is my Amazon DynamoDB table being throttled?Follow"


Question: How do I configure CORS in Amazon S3 and confirm the CORS rules using cURL?

"I want to allow cross-origin access to resources in my Amazon Simple Storage Service (Amazon S3) bucket, but I'm getting an error."

Answer: "I want to allow cross-origin access to resources in my Amazon Simple Storage Service (Amazon S3) bucket, but I'm getting an error.ResolutionYou can apply Cross-Origin Resource Sharing (CORS) rules to your bucket using either the Amazon S3 console or AWS Command Line Interface (AWS CLI). To test the CORS rules on your Amazon S3 bucket, use the cURL command. CORS is a feature of HTTP that uses headers to allow browsers to display content which a web server requested from a different origin. If you make a cross-origin request to an Amazon S3 bucket that isn't defined by a CORS rule, then the CORS header isn't returned.For example:curl -i http://mycorsbucket.s3.amazonaws.com/cors-test.html -H "Origin: http://www.example.com"HTTP/1.1 200 OKx-amz-id-2: Va106gWx1uUDGbouopXfpjvjHW0VXydI8/VGlraf/62f2vvxtI+iAnmu7lF4MK2B6CxuzReyfRI=x-amz-request-id: QWNNX1Y0MWFM152HDate: Thu, 04 Nov 2021 18:52:55 GMTLast-Modified: Thu, 04 Nov 2021 16:03:50 GMTETag: "cd4276d2cd5a2dc8ebcc1e04746680f6"Accept-Ranges: bytesContent-Type: text/htmlServer: AmazonS3Content-Length: 55If a web server made a similar request to a website, the content retrieved from your bucket won't appear in your browser. To allow your content to appear, configure a CORS policy on your Amazon S3 bucket. Proper configuration of the CORS policy makes sure that the appropriate headers are returned. You can configure a CORS rule on your bucket using the Amazon S3 console or AWS CLI.Configuring a CORS rule using the Amazon S3 consoleTo configure a CORS rule on your bucket using the Amazon S3 console, perform the following steps:1.    Sign in to the AWS Management Console.2.    Open the Amazon S3 console.3.    Select your bucket.4.    Choose the Permissions tab.5.    In the Cross-origin resource sharing pane, choose Edit.6.    In the text box, enter the JSON CORS rule that you want to activate:Example:[  {    "AllowedHeaders": [      "Authorization"    ],    "AllowedMethods": [      "GET",      "HEAD"    ],    "AllowedOrigins": [      "http://www.example.com"    ],    "ExposeHeaders": [      "Access-Control-Allow-Origin"    ]  }]For more information about each of the CORS rule elements or example rules, see CORS configuration.7.    Choose Save.Configuring a CORS rule using the AWS CLITo configure a CORS rule on your bucket using the AWS CLI, run the following command:aws s3api put-bucket-cors --bucket mycorsbucket --cors-configuration '{"CORSRules" : [{"AllowedHeaders":["Authorization"],"AllowedMethods":["GET","HEAD"],"AllowedOrigins":["http://www.example.com"],"ExposeHeaders":["Access-Control-Allow-Origin"]}]}'Note: If you receive errors when running AWS CLI commands, make sure that you're using the most recent version of the AWS CLI.Testing the CORS ruleTo test the CORS rule, use the cURL command, like this:curl -i http://mycorsbucket.s3.amazonaws.com/index.html -H "Origin: http://www.example.com"HTTP/1.1 200 OKx-amz-id-2: d5Jsw1vCf8tR3cMdXrtcTKYgczU/1pjxahnrw7C6jU1fLo8py2Nv2kpeFs8pYPruVZg6Y3JuRUA=x-amz-request-id: BMCCY18E58B3GBWVDate: Thu, 04 Nov 2021 19:12:26 GMTAccess-Control-Allow-Origin: http://www.example.comAccess-Control-Allow-Methods: GET, HEADAccess-Control-Expose-Headers: Access-Control-Allow-OriginAccess-Control-Allow-Credentials: trueVary: Origin, Access-Control-Request-Headers, Access-Control-Request-MethodLast-Modified: Thu, 04 Nov 2021 16:03:50 GMTETag: "cd4276d2cd5a2dc8ebcc1e04746680f6"Accept-Ranges: bytesContent-Type: text/htmlServer: AmazonS3Content-Length: 55If the CORS rule is correctly configured, you receive a 200 OK response.Troubleshooting CORS methodsIf you encounter unexpected behavior while accessing buckets with the CORS configuration, try the following:1.    Use the cURL command to make requests using specific CORS methods by adding the -H "Access-Control-Request-Method: <Method>" flag. This flag specifies the CORS method to be tested. Use the --request OPTIONS flag to perform a preflight check of the request.Note: Amazon S3 supports the GET, HEAD, PUT, POST, and DELETE methods.curl -i http://mycorsbucket.s3.amazonaws.com/cors-test.html -H "Access-Control-Request-Method: POST" --request OPTIONS -H "Origin: http://www.example.com"HTTP/1.1 403 Forbiddenx-amz-request-id: 190J4Q6222HA2KZ5x-amz-id-2: 6oEci3qg88OeoLvBGwkN8K9AGdxyVela8ZKxftXMqyWrtZFfiKMrBwpTAeRiOth8amovJMtAAdA=Content-Type: application/xmlTransfer-Encoding: chunkedDate: Fri, 19 Nov 2021 18:43:38 GMTServer: AmazonS3<?xml version="1.0" encoding="UTF-8"?><Error>AccessForbidden<Message>CORSResponse: This CORS request is not allowed. This is usually because the evalution of Origin, request method / Access-Control-Request-Method or Access-Control-Request-Headers are not whitelisted by the resource's CORS spec.</Message><Method>POST</Method><ResourceType>OBJECT</ResourceType><RequestId>190J4Q6222HA2KZ5</RequestId><HostId>6oEci3qg88OeoLvBGwkN8K9AGdxyVela8ZKxftXMqyWrtZFfiKMrBwpTAeRiOth8amovJMtAAdA=</HostId></Error>2.    If the request returns an error, verify that the CORS configuration is set on the bucket. Be sure that you added the required method to the CORS rule on your bucket. If the CORS configuration is set, you see the option to edit the CORS configuration in the Permissions section for bucket in the S3 console.aws s3api put-bucket-cors --bucket mycorsbucket --cors-configuration '{"CORSRules" : [{"AllowedHeaders":["Authorization"],"AllowedMethods":["GET","HEAD","POST"],"AllowedOrigins":["http://www.example.com"],"ExposeHeaders":["Access-Control-Allow-Origin"]}]}'3.    Test the updated CORS rule. If your method works as expected, you receive the following response:curl -i http://mycorsbucket.s3.amazonaws.com/index.html -H "Access-Control-Request-Method: POST" -X OPTIONS -H "Origin: http://www.example.com"HTTP/1.1 200 OKx-amz-id-2: Cx4kuM31KPVE19woEPRRYxF+85vEWkLk8+M0p6BIb72T550njMnmLtjqRgYzuxKelR0f+cxhFqI=x-amz-request-id: QBSHV46QK43HGW15Date: Fri, 19 Nov 2021 18:48:21 GMTAccess-Control-Allow-Origin: http://www.example.comAccess-Control-Allow-Methods: GET, HEAD, POSTAccess-Control-Expose-Headers: Access-Control-Allow-OriginAccess-Control-Allow-Credentials: trueVary: Origin, Access-Control-Request-Headers, Access-Control-Request-MethodServer: AmazonS3Content-Length: 04.    Capture the complete request and response using a tool of your choice. For each request that Amazon S3 receives, you must have a CORS rule that matches the data in your request.Verify that the request has the Origin header. If the header is missing, Amazon S3 doesn't treat the request as a cross-origin request, and doesn't send CORS response headers in the response.Verify that the Origin header in your request matches at least one of the AllowedOrigins elements in the specified CORSRule. The scheme, host, and port values in the Origin request header must match the AllowedOrigins elements in the CORSRule. For example, suppose you set the CORSRule to allow the origin http://www.example.com. When you do this, https://www.example.com and http://www.example.com:80 origins in your request don't match the allowed origin in your configuration.Verify that the method in your request or preflight request (method that's specified in the Access-Control-Request-Method) is one of the AllowedMethods elements in the same CORSRule.If a preflight request includes an Access-Control-Request-Headers header, verify that the CORSRule includes the AllowedHeader entries for each value in the Access-Control-Request-Headers header.Related informationAdding HTTP headers to Amazon CloudFront responsesHow do I resolve the "No 'Access-Control-Allow-Origin' header is present on the requested resource" error from CloudFront?How does Amazon S3 evaluate the CORS configuration on a bucket?Troubleshoot CORSFollow"


Question: How can I access a bucket in another account using an S3 access point restricted to a VPC?

I have an AWS Identity and Access Management (IAM) entity and bucket in different AWS accounts. I want to grant the IAM entity cross-account access to the bucket using an Amazon Simple Storage Service (Amazon S3) access point restricted to an Amazon Virtual Private Cloud (Amazon VPC).

Answer: "I have an AWS Identity and Access Management (IAM) entity and bucket in different AWS accounts. I want to grant the IAM entity cross-account access to the bucket using an Amazon Simple Storage Service (Amazon S3) access point restricted to an Amazon Virtual Private Cloud (Amazon VPC).ResolutionTo grant an IAM role or user in an AWS account (Account A) access to an Amazon S3 bucket in another AWS account (Account B) using an S3 access point restricted to an Amazon VPC, do the following:Create and attach an Amazon S3 access point to the bucket in Account B.Create an Amazon S3 VPC Gateway endpoint in Account A.Attach the access point, Bucket, and IAM policies.Create and attach an Amazon S3 access point to bucket in Account BOpen the Amazon S3 console.In the navigation pane, choose Access Points.Choose Create access point.For Access point name, enter a name for the access point. For more information, see Rules for naming Amazon S3 access points.For Bucket name, enter the name of the bucket from Account B you want to attach the access point to.Choose Virtual Private Cloud (VPC) for Network Origin.For VPC ID, enter the VPC ID from the first AWS account (Account A).Under Block Public Access settings for this Access Point, choose the block public access settings you want to apply to the access point. Note: Amazon S3 currently doesn't support changing an access point's block public access settings after the access point has been created.Leave Access Point policy blank.Choose Create access point.Create an Amazon S3 VPC Gateway endpoint in Account ACreate an S3 Gateway VPC endpoint in the initial AWS account (Account A) in the same Region as the bucket you're granting cross-account access to.Open the Amazon VPC console.In the navigation pane, choose Endpoints.Choose Create endpoint.For Service category, choose AWS services.For Services, add the filter Type: Gateway and select the same region used to create the access point.For VPC, choose the same VPC used to create the access point.For Route tables, choose the route tables to be used by the endpoint.Choose Full access policy. Or, choose Custom and be sure the policy permits the required S3 actions.Note: Gateway endpoints don't allow access from other AWS Regions. Below is an example VPC endpoint policy that permits all S3 actions to all buckets:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Principal": "*","Action": "s3:*","Resource": "arn:aws:s3:*"}]}Attach the access point, Bucket, and IAM policiesTo allow the initial AWS account's (Account A) IAM entity cross-account access to the other AWS account's (Account B) bucket via the access point, you must grant permissions from the access point, bucket and IAM polices. Below are the policies that grant the required permissions for each.Access point policy:{"Version": "2012-10-17","Statement": [{"Sid": "DelegateControlToAccessPoint","Effect": "Allow","Principal": {"AWS": ["arn:aws:iam::AccountA-ID:user/user1","arn:aws:iam::AccountA-ID:role/role01"]},"Action": ["s3:ListBucket","s3:PutObject","s3:GetObject"],"Resource": ["arn:aws:s3:us-east-2:AccountB-ID:accesspoint/my-acess-point/object/*","arn:aws:s3:us-east-2:AccountB-ID:accesspoint/my-access-point"]}]}Note: This policy grants the IAM user or role from the source AWS account (Account A) permission to the access point in the target AWS account (Account B).Bucket policy:{"Version": "2012-10-17","Statement": [{"Sid": "AllowCrossAccountAccess","Effect": "Allow","Principal": {"AWS": ["arn:aws:iam::AccountA-ID:user/user1","arn:aws:iam::AccountA-ID:role/role01"]},"Action": ["s3:GetObject","s3:ListBucket","s3:PutObject"],"Resource": ["arn:aws:s3:::my-bucket","arn:aws:s3:::my-bucket/*"],"Condition": {"StringEquals": {"s3:DataAccessPointArn": "arn:aws:s3:us-east-2:AccountB-ID:accesspoint/my-access-point"}}}]}Note: This policy grants the source AWS account's (Account A) IAM user permission to the bucket (Account B) by using the access point.IAM policy: {"Version": "2012-10-17","Statement": [{"Sid": "AllowCrossAccountAccessToBucketAndAP","Effect": "Allow","Action": ["s3:ListBucket","s3:PutObject","s3:GetObject"],"Resource": ["arn:aws:s3:us-east-2:AccountB-ID:accesspoint/my-access-point","arn:aws:s3:us-east-2:AccountB-ID:accesspoint/my-access-point/object/*","arn:aws:s3:::my-bucket","arn:aws:s3:::my-bucket/*"]}]}Note: This IAM policy attached to the source AWS account's (Account A) IAM role or user grants permission to the target AWS account's (Account B) bucket and access point.AWS CLI command examples to perform S3 operations against the bucket using the access point:Note: If you receive errors when running AWS CLI commands, make sure that you're using the most recent version of the AWS CLI.List:aws s3 ls arn:aws:s3:us-east-2:AccountB-ID:accesspoint/my-access-pointUpload:aws s3 cp file.txt s3://arn:aws:s3:us-east-2:AccountB-ID:accesspoint/my-access-pointDownload:aws s3 cp s3://arn:aws:s3:us-east-2:AccountB-ID:accesspoint/my-access-point file.txtNote: The request must originate from an Amazon Elastic Compute Cloud (Amazon EC2) instance in the VPC and in the same region as the bucket.Follow"


Question: How do I increase the available disk space on my Amazon ECS container instances if I launched my container instances as standalone Amazon EC2 instances?

How do I increase the available disk space on my Amazon Elastic Container Service (Amazon ECS) if I launched my container instances as standalone Amazon Elastic Compute Cloud (Amazon EC2) instances?

Answer: "How do I increase the available disk space on my Amazon Elastic Container Service (Amazon ECS) if I launched my container instances as standalone Amazon Elastic Compute Cloud (Amazon EC2) instances?Short descriptionTo increase the storage space on your container instances, you must launch replacement instances, and then terminate your original instances.To increase the storage space using this method, complete the steps in the Resolution section. If you launched your container instances using another method, then skip this article and complete the steps in one of the following articles:How do I increase the available disk space on my Amazon ECS container instances if I launched my ECS cluster from the AWS Management Console?How do I increase the available disk space on my Amazon ECS container instances if I launched my cluster manually with an Auto Scaling group?Note: Your Amazon Elastic Block Store (Amazon EBS) volume configuration varies depending on which Amazon ECS-optimized Amazon Machine Image (AMI) you're using. For more information and commands on how to check the available space on your instances, see AMI storage configuration.Important: The following steps terminate the original container instances in your Amazon ECS cluster. Any data that's stored on the EBS volumes for those instances will be lost.ResolutionLaunch replacement instancesImportant: To avoid downtime for your Amazon ECS services, you must launch replacement instances before draining your original container instances. After all the tasks stop on the original container instances, confirm that the tasks on the replacement instances started, and then terminate the original container instances.1.    Open the Amazon EC2 console.2.    From the navigation pane, choose Instances.3.    In the Instance ID column for each of your original ECS container instances, note the instance ID.4.    Select one of your original container instances.5.    (New EC2 Experience) Choose Actions, choose Image and templates, and then choose Launch more like this.(Old EC2 console) Choose Actions, and then choose Launch more like this.Note: The Launch more like this option pre-populates the Launch an instance window with the options from your original container instances. You can then update the configuration to increase the EBS volume or any other configuration updates.6.    Choose the Step 4: Add Storage page.7.    For Size (GiB), enter a value to increase the size of your volume.Note: For more information on volume options, see Block device mappings.8.    (Optional) To update the number of instances that you want to launch, choose 3. Configure Instance, and then enter the number of instances for Number of instances.9.    (Optional) To update the AMI ID to the latest Amazon ECS-optimized AMI, choose 1. Choose AMI, and then enter the AMI ID for your AWS Region.10.    Choose Review and Launch, and then choose Launch.Drain the previous ECS container instances to migrate containers to new instances1.    Open the Amazon ECS console.2.    Choose the cluster in which your container instance is grouped.3.    (New ECS Experience) Choose the Infrastructure tab, and then select the original container instances by the instance IDs that you noted earlier.(Old ECS console) Choose the ECS Instances tab, and then select the original container instances by the instance IDs that you noted earlier.4.    Choose Actions, and then choose Drain instances.Note: You can drain the previous instances in batches to avoid downtime for your Amazon ECS services. When you drain service tasks for container instances, container instances in the RUNNING state are stopped and replaced according to the service's deployment configuration parameters, minimumHealthyPercent and maximumPercent. Any PENDING or RUNNING tasks that don't belong to the service are unaffected. You must wait for these tasks to finish or stop them manually.5.    When the DRAINING instances have 0 running tasks, repeat steps 2-3 until all of the original container instances are in DRAINING status.6.    Terminate the original instances.Your tasks should now be running on the new instances with more storage available.Related informationAMI storage configurationContainer instance drainingUsing data volumes in tasksFollow"


Question: Why can't I run Spark applications on my EMR notebook?

I can't run my Apache Spark application on my Amazon EMR notebook

Answer: "I can't run my Apache Spark application on my Amazon EMR notebookShort descriptionSpark applications run from an EMR notebook might fail to start with the following exception:The code failed because of a fatal error:Session 4 did not start up in 60 seconds.ResolutionThe following are common troubleshooting steps for running Spark applications on your EMR notebook:Check the resources on the clusterMake sure that Spark has enough available resources in the cluster for Jupyter to create a Spark context. You can check available resources using Amazon CloudWatch metrics or the Resource Manager.Make sure that the Sparkmagic libraries are configured correctlyContact your Jupyter administrator to make sure that the Sparkmagic libraries are configured correctly.Restart the notebook kernel1.    Open the EMR console and then select Notebook.2.    Select the notebook from the Notebooks list, and then choose Open in JupyterLab or Open in Jupyter. A new browser tab opens to the JupyterLab or Jupyter Notebook editor.3.    From the Kernel menu, select Restart Kernel.Increase the Spark session timeout period for JupyterLabTo increase the Spark session timeout period, do the following:1.    Open the EMR console and select Notebook.2.    Select the notebook from the Notebooks list.3.    Access the EMR notebook's Jupyter web user interface.4.    Open the EMR notebook terminal.5.    Open the config.json file using the following command:vi /home/notebook/.sparkmagic/config.json5.    Add or update the livy_session_startup_timeout_seconds: xxx option in the config.json file.6.    Restart all kernels.Note: If the JupyterHub application is installed in the EMR primary instance, then do the following to increase the Spark session timeout period.1.    Run the following command:vi /etc/jupyter/conf/config.json2.    Update the livy_session_startup_timeout_seconds:60 option to your value and then restart the JupyterHub container.Tune Spark driver memoryTune the Spark driver memory used by the Jupyter notebook application to control the resource allocation. For more information, see How can I modify the Spark configuration in an Amazon EMR notebook?Make sure that the Apache Livy service is healthyCheck the status of the Livy server running on the primary node instance1.    Use the following command to check the status of the livy-server:sudo systemctl status livy-server2.    Use the following command to restart the livy-server if the status is down:sudo systemctl start livy-serverIncrease the Livy Server memoryBy default, the notebook client attempts to connect to Livy Server for 90 seconds. If the Livy server doesn't respond within 90 seconds, then the client generates a timeout. The most common reason why Livy server isn't responding is lack of enough resources. To fix this, increase the memory for Livy server:1.    Connect to the primary node instance using SSH.2.    Add the following property to the file /etc/livy/conf/livy-env.sh:export LIVY_SERVER_JAVA_OPTS="-Xmx8g" (option to your value)3.    For the changes to take effect, restart the Livy server.sudo systemctl stop livy-serversudo systemctl start livy-serverUse cluster mode instead of client mode in LivySpark applications are submitted on the notebook in client mode and the Spark driver runs as the sub process of the Livy server. Running as a sub process might cause a lack of resources on the primary node. To prevent Livy from failing due to insufficient resources, change deployment mode to cluster mode. Running on cluster mode, the driver runs on the application primary in the core and task nodes rather than on the primary node.To use cluster mode, do the following:1.    Connect to the primary node using SSH.2.    Add the following parameter to the file /etc/livy/conf/livy.conf:livy.spark.deploy-mode  cluster3.    For the changes to take effect, restart the Livy server:sudo systemctl stop livy-serversudo systemctl start livy-serverFollow"


Question: How do I connect different branch offices using AWS Site-to-Site VPN and AWS Direct Connect?

I want to establish connectivity between branch offices using AWS Site-to-Site VPN and AWS Direct Connect.

Answer: "I want to establish connectivity between branch offices using AWS Site-to-Site VPN and AWS Direct Connect.Short descriptionAWS Site-to-Site VPN provides secured connectivity between AWS resources and the on-premises network such as a data center or a branch office.AWS Direct Connect provides connectivity to AWS resources by establishing a link between your internal network and the AWS Direct Connect location.Use Site-to-Site VPN and AWS Direct Connect's transit virtual interface (VIF) to establish connectivity between the branch offices.ResolutionEstablish the Site-to-Site VPN connection through a transit gateway from your branch office (for example, Branch office 1). Then, establish AWS Direct Connect from the second branch office (for example, Branch office 2) to the same transit gateway that you used to set up Site-to-Site VPN.Branch office 1Complete these steps to set up the AWS Direct Connect connection through the transit gateway:Request AWS Direct Connect between an AWS Direct Connect location and Branch office 1.Create an AWS Direct Connect transit VIF to the Direct Connect gateway.Associate the transit gateway to the AWS Direct Connect gateway.Note: List Branch office 2's network prefixes in Allowed prefixes.Using Border Gateway Protocol (BGP), advertise Branch office 1's CIDR from an on-premises device towards the transit VIF. For more information on configuring your on-premises device, see the device's third-party documentation for details.Branch office 2Complete these steps to set up a Site-to-Site VPN connection in this branch:Establish Site-to-Site VPN through the same transit gateway used for the transit VIF in Branch office 1.Using BGP, advertise Branch office 2's network prefixes from the customer gateway device towards the Site-to-Site VPN.Note:Make sure that the Site-to-Site VPN attachment and the AWS Direct Connect gateway attachment associate with the same transit gateway routing table.The Autonomous System Number (ASN) for Transit Gateway, AWS Direct Connect gateway, and the branch offices must be unique.Follow"


Question: Why does the new Amazon EBS volume I created from an encrypted snapshot not exist?

"I created an Amazon Elastic Block Store (Amazon EBS) volume from an encrypted snapshot using the AWS Command Line Interface (AWS CLI) create-volume. The command successfully completes and returns a volume ID. When I try to attach the volume to an instance, I can't find the volume. Why does the new EBS volume that I created from an encrypted snapshot not exist?"

Answer: "I created an Amazon Elastic Block Store (Amazon EBS) volume from an encrypted snapshot using the AWS Command Line Interface (AWS CLI) create-volume. The command successfully completes and returns a volume ID. When I try to attach the volume to an instance, I can't find the volume. Why does the new EBS volume that I created from an encrypted snapshot not exist?Short descriptionWhen you create an Amazon EBS volume from a snapshot, two operations run:First, Amazon EBS initiates the volume creation. This returns a volume ID, and sets the volume state to creating (as returned in the API/AWS CLI output). This means that the CreateVolume API is valid and registered successfully.Next, an asynchronous call initiates to validate the KMS key used to encrypt and decrypt the volume you are creating.If the KMS validation succeeds, then the volume state is set to available, and the EBS volume becomes accessible. But, if the specified KMS key ID, Alias, or ARN are not valid, then the action might appear as complete, but eventually fails with no errors returned.Note: The KMS validation for CreateVolume is asynchronous. For more information, see create-volume and Encrypting EBS resources.You might only notice the problem when you try to attach or access the EBS volume. You then find that it doesn't exist, despite the CreateVolume API returning a volume ID. Also, if you check the AWS CloudTrail logs, you will not see any errors.Example of issueThis example shows the CreateVolume API in use with an invalid alias for the KMS key. The CreateVolume API succeeds and returns a volume ID, and then sets the volume state to creating. Because the alias for the KMS key isn't valid, the asynchronous authentication fails. This causes the whole operation to fail. When you check the AWS CloudTrail logs for the create volume event, no errors are found because the CreateVolume operation succeeded.$ aws ec2 create-volume --volume-type gp2 --availability-zone eu-west-1c --encrypted --kms-key-id hana --snapshot-id snap-0a27fe340500641d9 {    "AvailabilityZone": "eu-west-1c",     "MultiAttachEnabled": false,     "Tags": [],     "Encrypted": true,     "VolumeType": "gp2",     "VolumeId": "vol-043fe27d0ccf74b36",     "State": "creating",     "KmsKeyId": "hana",     "SnapshotId": "snap-0a27fe340500641d9",     "Iops": 100,     "CreateTime": "2020-10-06T18:03:09.000Z",     "Size": 8}AWS CloudTrail logs:responseElements": {        "requestId": "8677d3cd-ad1d-4866-95f5-375d92a35813",        "volumeId": "vol-043fe27d0ccf74b36",        "size": "8",        "snapshotId": "snap-0a27fe340500641d9",        "zone": "eu-west-1c",        "status": "creating",        "createTime": 1602007389000,        "volumeType": "gp2",        "iops": 100,        "encrypted": true,        "masterEncryptionKeyId": "hana",        "tagSet": {},        "multiAttachEnabled": false    },    "requestID": "8677d3cd-ad1d-4866-95f5-375d92a35813",    "eventID": "bd4216df-ba39-425e-b272-936212ae6699",    "eventType": "AwsApiCall",    "recipientAccountId": "864258534754"}When you run the describe-volume-status, you find that the volume doesn't exist:$ aws ec2 describe-volume-status --volume-ids vol-043fe27d0ccf74b36An error occurred (InvalidVolume.NotFound) when calling the DescribeVolumeStatus operation: The volume 'vol-043fe27d0ccf74b36' does not exist.ResolutionNote: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.Use the describe-volume-status APIUse the describe-volume-status API to check if the EBS volume exists.Subscribe to the CloudWatch CreateVolume eventsSubscribe to the public CloudWatch CreateVolume events for more information on volume creation failure. This is an example notification that you might receive. It notifies you of the CreateVolume CloudWatch event. From the notification, you get more insight into the event, and you can see that the CreateVolume result failed because of an Invalid keyId.AWS Notification MessageCreateVolume <no-reply@sns.amazonaws.com>{"version":"0","id":"192e695f-2387-1cf0-fb1c-1cb32f047212","detail-type":"EBS Volume Notification","source":"aws.ec2","account":"12345678","time":"2020-10-06T18:03:10Z","region":"eu-west-1","resources":["arn:aws:ec2:eu-west-1:864258534754:volume/vol-043fe27d0ccf74b36"],"detail":{"result":"failed","cause":"Invalid keyId hana","event":"createVolume","request-id":"8677d3cd-ad1d-4866-95f5-375d92a35813"}}Note: If you create an EBS volume from an encrypted snapshot, it can also fail to create for following reasons:The AWS Identity and Access Management (IAM) user/role creating the volume doesn't have sufficient permissions to access the KMS key used to encrypt the snapshot.The KMS key used to encrypt the snapshot has been disabled, deleted or is not in the Region.Related informationHow can I optimize the performance of my Amazon EBS volumes?Why can't I find the user name that created an EBS volume by searching CloudTrail events logs?Follow"


Question: Why can't I resend the validation email from ACM when renewing a certificate?

"I am renewing a certificate using AWS Certificate Manager (ACM), and I want to resend the validation email. However, the option is unavailable, or I receive an error message. How do I resolve this issue?"

Answer: "I am renewing a certificate using AWS Certificate Manager (ACM), and I want to resend the validation email. However, the option is unavailable, or I receive an error message. How do I resolve this issue?Short descriptionIf you use email to validate domain ownership, then ACM sends emails to the three contact addresses listed in WHOIS and to the five common system addresses for the domains specified in the certificate request. If the certificate's renewal status is pending validation, you can request a domain validation email for certificate renewal.You can't resend the validation email if:The certificate renewal status isn't pending validation.The certificate renewal status is pending validation, and the subject alternative name (SAN) doesn't have the domain validation status as pending validation.The domain was validated using Domain Name System (DNS).ResolutionThe certificate renewal status isn't pending validationNote: 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.Check the certificate's renewal status. If the certificate renewal status isn't pending validation, then the option to resend the validation email is unavailable (grayed out), or you receive the following error message:Certificate arn:aws:acm:region:123456789012:certificate/97b4deb6-8983-4e39-918e-ef1378924e1e is not using EMAIL validation for domain example.com.If the certificate's renewal status is pending validation, then resend the validation email.If the certificate's renewal status is failed, then you can't request to resend the validation email. Instead, you must request a public certificate.The certificate renewal status is pending validation, and the SAN doesn't have the domain validation status as pending validationDuring the renewal process, if at least one of your domains is automatically validated and you attempt to resend validation emails for the same domains, then you receive the following error:Certificate arn:aws:acm:region:123456789012:certificate/97b4deb6-8983-4e39-918e-ef1378924e1e is not using EMAIL validation for domain example.com.To confirm which domains must be validated, use the AWS CLI command for describe-certificate. You can use the AWS CLI to specify the base validation domain for the email that isn't validated. For more information, see  resend-validation-email.Note: You can only resend validation emails for domains with the renewal status as pending validation.The domain was validated using DNSIf you use DNS to validate domain ownership, the validation email can't be sent again, and the option to resend the validation isn't available (grayed out) in the ACM console. If you're using the AWS CLI, you might receive the following error message:An error occurred (InvalidStateException) when calling the ResendValidationEmail operation: Certificate arn:aws:acm:us-arn:aws:acm:region:123456789012:certificate/97b4deb6-8983-4e39-918e-ef1378924e1e is not using EMAIL validation for domain example.com.Related informationWhy am I not receiving validation emails when using ACM to issue or renew a certificate?Troubleshoot email validation problemsFollow"


Question: How do I import data into my Amazon RDS DB instance?

How can I import data from my existing database into an Amazon Relational Database Service (Amazon RDS) instance with minimal downtime?

Answer: "How can I import data from my existing database into an Amazon Relational Database Service (Amazon RDS) instance with minimal downtime?Short descriptionTo import data from an existing database to an RDS DB instance:Export data from the source database.Upload the exported data.Import the uploaded data into an RDS DB instance.The data import process requires varying amounts of server downtime depending on the size of the source database that is imported. The required downtime is also affected by the database engine type used by the destination DB instance. See the following DB-specific resolutions for more information.ResolutionGeneral data import performance guidelinesThe following performance guidelines apply to all Amazon RDS data import/export operations:Load and unload data in parallel using compression and multiple threads. If you're loading a large amount of data in parallel, be sure that the client machine has sufficient resources during the data load process.Consider disabling automated backups for large data loads by setting the backup retention for the RDS DB instance to zero. You must reboot the RDS DB instance to apply this change. Important: Disabling backups is not recommended for production instances, because this prevents point-in-time recovery functionality, deletes all previous automated snapshots for the DB instance, and prevents recovery of deleted snapshots. However, if the DB instance is not yet in production, disabling backups can improve load performance. After the data load is complete, be sure to enable automated backups. Also consider creating DB snapshots at critical stages of the data load process, so that you can restore your instance from a snapshot, if necessary.Consider disabling Multi-AZ during the data load operation to reduce the overhead caused by the synchronous write operations of Multi-AZ data loads. Important: Multi-AZ functionality is a best practice for all production RDS DB instances, and Multi-AZ should be enabled as soon as the data load is complete.Database engine-specific data import guidelinesImporting Data to an Amazon RDS MySQL or MariaDB – You can use MySQL tools, such as mysqldump, mysql, and replication, to import data to Amazon RDS. Replication using MySQL 5.6.13 and later can replicate data to and from an external RDS DB instance. When importing data into a MariaDB DB instance, you can use MariaDB tools such as mysqldump, mysql, and standard replication to import data to Amazon RDS.Importing Data into PostgreSQL on Amazon RDS – You can use PostgreSQL tools such as pg_dump, psql, and the copy command to import data to Amazon RDS.Importing Data into Oracle on Amazon RDS – Small databases can use the Database Copy feature available with Oracle SQL Developer. Larger databases require a data pump to export and import using a database link and file transfer to the directory that's defined on the RDS DB instance when specifying export parameters.Importing and Exporting SQL Server Databases – You can use native backup and restore for Microsoft SQL Server databases by using .bak files. You can also create a full backup of your on-premises database, store the backup on Amazon Simple Storage Service (Amazon S3), and then restore the backup file to Amazon RDS.Importing Data into Aurora MySQL – Similarly to importing into Amazon RDS, you can use to native tools such as mysqldump and mydumper to migrate to Amazon Aurora for MySQL. You can use Aurora MySQL compatible binary log replication to reduce downtime. You can also migrate to Aurora MySQL by using Percona Xtrabakup stored on Amazon S3, by using a snapshot of an Amazon RDS MySQL DB instance, or by creating an Aurora replica of an existing RDS MySQL DB instance. For all migration options, be sure that all source tables are converted to InnoDB Storage engine with dynamic row format. This helps accelerate the speed of your migration, and helps achieve a successful migration to Aurora. For more information, see Best Practices for Migrating MySQL Databases to Amazon Aurora.Using AWS Database Migration Service (AWS DMS) - You can use AWS DMS to import data from on-premise environments to AWS. DMS offers both homogeneous and heterogeneous migrations with minimal downtime. DMS offers the following migration types:Migrate existing data (full load) – Move existing data from the source to the target database instance. This is a one-time load, and it's similar to the import and export options listed previously. This migration type is best for small and medium databases that can afford considerable downtimeMigrate existing data and replicate ongoing changes (full load + change data capture (CDC)) – To migrate data with minimal downtime, AWS DMS can migrate the existing data and replicate the data changes from the source to the target until the cutover. This migration type is best for small and medium databases that require minimal downtime, which only lasts for the duration of the cutover.Replicate data changes only (CDC) – Use the efficiency of the native import and export tools to migrate the existing data and set up a CDC-only task that captures ongoing changes from the source to the target instance. The CDC custom start time parameter specifies the point in time to start the data sync. This migration type is best for medium and large databases that require minimal downtime lasting only for the duration of the cutover.Related informationExporting Data from a MySQL DB Instance by Using ReplicationBest Practices for Amazon RDSMigrating Databases to Amazon Web Services (AWS)Follow"