Question: How do I port my phone number that's registered in the US or Canada (+1 country code) in Amazon Connect?

"I am trying to port my US (+1 country code) numbers in Amazon Connect, but I am unsure of how to do this. How do I start the process for porting my numbers?"

Answer: "I am trying to port my US (+1 country code) numbers in Amazon Connect, but I am unsure of how to do this. How do I start the process for porting my numbers?ResolutionCreate a support case to port your numbers into Amazon Connect. Before you submit your case, determine if your number is a toll-free number (TFN) or a direct inward dial (DID) number. Toll-free numbers have an area code that begins with an "8" and that repeats the next two numbers. These TFNs include the following area codes:800833844855866877If your number doesn't follow this pattern, your phone number is a DID number.Note: This process is for phone numbers registered in the US or Canada. For all other numbers, see How do I port my phone number that's not registered in the US or Canada (+1 country code) in Amazon Connect?Porting toll-free numbersIf you are porting toll-free numbers, include the following information when submitting your case to AWS Support:Connect instance ARN where the number will resideToll-free number or numbers in E.164 format(Optional) Exact name of the contact flow where the numbers must be mapped to after receiving porting approvalNote: Specifying the contact flow information allows AWS Support to map the number to a contact flow when adding the number to the Amazon Connect instance. This helps to avoid downtime during the porting process. For information on mapping the number to a contact flow, see Associate a phone number with a flow.(Optional) Copy of an invoice or bill with your current carrier, with sensitive information redactedPreferred porting window timeframeNote: AWS Support will attempt to meet the window timeframe, but can't guarantee to meet it.After AWS Support collects all additional information and completed forms from you, the information is submitted to our partner carrier. Then, the partner carrier submits the port request to the current carrier. If the current carrier accepts the request to port, your preferred porting window timeframe is considered.The porting process takes from two to four weeks after all completed forms are submitted.The porting process is completed on the scheduled date and time that AWS Support provides to you.AWS Support informs you when the process is complete and successful porting has been verified. It's best practice for you to test the ported numbers by placing test calls to make sure that the attached contact flow is initiated.Note: If there are any discrepancies between the information submitted by you and the current carrier's records, the current carrier will reject the porting request. AWS Support will reach out to you for the correct information, but this means that the porting process will be delayed.Porting DID numbersIf you are porting DID numbers, include the following information when submitting your case to AWS Support:Connect instance ARN where the number will resideList of DID number or numbers in E.164 format(Optional) Exact name of the contact flow where the numbers must be mapped to after receiving porting approvalNote: Specifying the contact flow information allows AWS Support to map the number to a contact flow when adding the number to the Amazon Connect instance. This helps to avoid downtime during the porting process. For information on mapping the number to a contact flow, see Associate a phone number with a flow.(Optional) Copy of an invoice or bill with your current carrier, with sensitive information redactedPreferred porting window timeframeNote: AWS Support will attempt to meet the window timeframe, but can't guarantee to meet it.After AWS Support collects all additional information and completed forms from you, the information is submitted to our partner carrier. Then, the partner carrier submits the port request to the current carrier. If the current carrier accepts the request to port, your preferred porting window timeframe is considered.The porting process takes from two to four weeks after all completed forms are submitted.The porting process is completed on the scheduled date and time that AWS Support provides to you.AWS Support will inform you when the process is complete and successful porting is verified. It's best practice for you to test the ported numbers by placing test calls to make sure that the attached contact flow is initiated.Note: If there are any discrepancies between the information submitted by you and the current carrier's records, the current carrier will reject the porting request. AWS Support will reach out to you for the correct information, but this means that the porting process will be delayed.Follow"


Question: How do I list all of my Amazon EBS snapshots with or without a specified key tag using the AWS CLI?

"I want to use the AWS Command Line Interface (AWS CLI) to list all my Amazon Elastic Block Store (Amazon EBS) snapshots. What commands are a best practice to use when I want to list all snapshots, with or without a specified tag key?"

Answer: "I want to use the AWS Command Line Interface (AWS CLI) to list all my Amazon Elastic Block Store (Amazon EBS) snapshots. What commands are a best practice to use when I want to list all snapshots, with or without a specified tag key?ResolutionNote: Before beginning this resolution, install and configure the AWS CLI.If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.List all EBS snapshots in a particular RegionThe following example command lists all EBS snapshots using the describe-snapshots operation in the Region us-east-1:aws ec2 describe-snapshots --owner-ids self  --query 'Snapshots[]' --region=us-east-1The following is example output for the describe-snapshots command:Created for policy: policy-08843cf0d7f6189ae schedule: Default Schedule    False    111122223333    100%    snap-091e33a177cb2e49b    2020-09-10T19:27:07.882Z    completed    vol-03b223394ea08e690    8TAGS    instance-id    i-0919c4d810b9c3695TAGS    dlm:managed    trueTAGS    timestamp    2020-09-10T19:27:07.548ZTAGS    aws:dlm:lifecycle-policy-id    policy-08843cf0d7f6189aeTAGS    aws:dlm:lifecycle-schedule-name    Default Scheduletest one hellop    False    111122223333    100%    snap-02faf8ffc48e512f4    2020-09-10T19:17:34.974Z    completed    vol-03b223394ea08e690    8 TAGS    ec2-console    falseCreated for policy: policy-08843cf0d7f6189ae schedule: Default Schedule    False    111122223333    100%    snap-007e74c24d8f3aaf1    2020-09-10T17:28:31.993Z    completed    vol-03b223394ea08e690    8TAGS    instance-id    i-0919c4d810b9c3695TAGS    dlm:managed    trueTAGS    aws:dlm:lifecycle-schedule-name    Default ScheduleTAGS    timestamp    2020-09-10T17:28:31.650ZTAGS    aws:dlm:lifecycle-policy-id    policy-08843cf0d7f6189aetest one     False    111122223333    100%    snap-00f20d2d2c17bbea0    2020-09-08T07:47:47.660Z    completed    vol-062b2c633c981f99e    8 TAGS    ec2-console    trueFilter the list of EBS snapshots for a specified tag keyThe following command lists EBS snapshots using the describe-snapshots operation with a specified tag key:aws ec2 describe-snapshots  --owner-ids self  --query 'Snapshots[?(Tags[?Key == `name`].Value)]'The following command lists all snapshots with the tag key ec2-console:$ aws ec2 describe-snapshots --owner-ids self --query 'Snapshots[?(Tags[?Key == `ec2-console`].Value)]'The following is an example output for the preceding command:test one hellop    False    111122223333    100%    snap-02faf8ffc48e512f4    2020-09-10T19:17:34.974Z    completed    vol-03b223394ea08e690    8 TAGS    ec2-console    falsetest one     False    111122223333    100%    snap-00f20d2d2c17bbea0    2020-09-08T07:47:47.660Z    completed    vol-062b2c633c981f99e    8 TAGS    ec2-console    trueFilter the list of EBS snapshots for snapshots that don't have a specified tag keyThe following command lists EBS snapshots that don't have a specified tag key:aws ec2 describe-snapshots --owner-ids self --query 'Snapshots[?!not_null(Tags[?Key == `name`].Value)]'The following example command filters the list of EBS snapshots for all snapshots that don't have the tag key ec2-console:$ aws ec2 describe-snapshots --owner-ids self --query 'Snapshots[?!not_null(Tags[?Key == `ec2-console`].Value)]'The following is an example output for the preceding command:Created for policy: policy-08843cf0d7f6189ae schedule: Default Schedule    False    111122223333    100%    snap-091e33a177cb2e49b    2020-09-10T19:27:07.882Z    completed    vol-03b223394ea08e690    8TAGS    instance-id    i-0919c4d810b9c3695TAGS    dlm:managed    trueTAGS    timestamp    2020-09-10T19:27:07.548ZTAGS    aws:dlm:lifecycle-policy-id    policy-08843cf0d7f6189aeTAGS    aws:dlm:lifecycle-schedule-name    Default ScheduleCreated for policy: policy-08843cf0d7f6189ae schedule: Default Schedule    False    111122223333    100%    snap-007e74c24d8f3aaf1    2020-09-10T17:28:31.993Z    completed    vol-03b223394ea08e690    8TAGS    instance-id    i-0919c4d810b9c3695TAGS    dlm:managed    trueTAGS    aws:dlm:lifecycle-schedule-name    Default ScheduleTAGS    timestamp    2020-09-10T17:28:31.650ZTAGS    aws:dlm:lifecycle-policy-id    policy-08843cf0d7f6189aeRelated informationTagging AWS resourcesFollow"


Question: Why did I get an email from AWS stating that my Amazon SNS subscription was manually disabled?

"I received an email from AWS saying that one of my Amazon Simple Notification Service (Amazon SNS) email subscriptions was manually disabled. Why was my Amazon SNS topic subscription deactivated, and how do I resolve the issue?"

Answer: "I received an email from AWS saying that one of my Amazon Simple Notification Service (Amazon SNS) email subscriptions was manually disabled. Why was my Amazon SNS topic subscription deactivated, and how do I resolve the issue?Short descriptionIf messages are published to an SNS topic at a higher rate than the Delivery rate for email messages quota, then Amazon SNS deactivates the subscription.Amazon SNS automatically deactivates subscriptions when TPS quotas are breached to do the following:Prevent spamming the destination inbox with events.Protect the recipient mail server from being flooded with messages.Avoid Internet Service Providers (ISPs) identifying elevated traffic as spam and blocking messages from delivery.Note: Amazon SNS supports an email message delivery rate of 10 transactions per second (TPS) to SNS topics, for each AWS account. For more information, see Amazon SNS endpoints and quotas.ResolutionIt's a best practice to avoid subscribing email addresses to high-volume SNS topics. Common use cases for SNS topic email subscriptions include monitoring Amazon CloudWatch alarms and sending usage reports to multiple email addresses.For high-volume SNS topics, it's a best practice to subscribe only high-throughput, system-to-system endpoints instead. For example: Amazon Simple Queue Service (Amazon SQS) queues, AWS Lambda functions, and HTTP endpoints. These types of subscription endpoints support a higher TPS quota.Related informationCommon Amazon SNS scenariosSending an email in Amazon PinpointSubscribing to an Amazon SNS topicPublishing to a topicFollow"


Question: My Amazon SES sending account is under review or its ability to send email is paused. How can I fix this?

"I received an email that my Amazon Simple Email Service (Amazon SES) sending account is under review. Or, my Amazon SES sending account's ability to send email is paused. Why is this happening? How can I fix this?"

Answer: "I received an email that my Amazon Simple Email Service (Amazon SES) sending account is under review. Or, my Amazon SES sending account's ability to send email is paused. Why is this happening? How can I fix this?Short descriptionIf your sending account is under review, you can still send emails through Amazon SES, but you must resolve the issue that led to the review. Additionally, you must implement measures to prevent the issue from occurring again. Issues that might lead to an account review include:A bounce rate of 5% or greaterA complaint rate of 0.1% or greaterProblems detected by a manual investigation of the accountIf your account's ability to send email is paused, then you can't use Amazon SES to send emails until you resolve the problem with the account. Your Amazon SES account uses a set of IP addresses that are shared with other users. Because of this, Amazon SES might pause your account's ability to send additional emails to protect the reputation of the shared IP addresses. Issues that might lead to a sending pause include:The Amazon SES account was already placed under review and the issue wasn't corrected before the end of the review period.A bounce rate of 10% or greaterA complaint rate is 0.5% or greaterThe account was placed under review several times for the same issue.Emails sent from the account violated AWS Service Terms.Important: An Amazon SES sending pause doesn't impact other AWS services in your AWS account. However, service quota increases for any AWS service that sends outbound communications, such as Amazon Simple Notification Service (Amazon SNS), might be denied until the sending pause is lifted.ResolutionIf Amazon SES is reviewing your sending account or has paused your account's sending ability, you must:Identify the problem.Request a new review and respond to follow-up questions from the Amazon SES team.Identify the problemRead the email from the Amazon SES team that summarizes the problems that led to the review or pause on your sending account. The issues that can lead to a review or pause on your account include bounces, complaints, and spam traps.Review the following FAQs for more information on reducing risk of these actions:Bounce FAQComplaint FAQSpamtrap FAQRequest a new review and respond to follow-up questions from the Amazon SES teamAfter you identify the problems with your sending account and take steps to fix them, request a new review from the Amazon SES team.To request a new review on your sending account, open the AWS Support Center. Then, reply to the case that Amazon SES opened on your behalf. In your reply, include your responses to these items:A list of changes that you made to fix the problemAn explanation of how these changes will prevent the problem from happening againAfter the Amazon SES team receives your request for a new review, they decide whether to uphold or remove the review or pause on your sending account. If your new review is unsuccessful, the Amazon SES team contacts you with follow-up questions. Be sure to respond to the Amazon SES team with the requested follow-up information.Related informationTips and best practices (Amazon SES Developer Guide)Four tips to help you send higher-quality emailFollow"


Question: How do I purchase an Amazon EC2 Reserved Instance?

"I have an Amazon Elastic Compute Cloud (Amazon EC2) instance that I plan to run continuously, with few interruptions, over a long period of time. How do I purchase a Reserved Instance?"

Answer: "I have an Amazon Elastic Compute Cloud (Amazon EC2) instance that I plan to run continuously, with few interruptions, over a long period of time. How do I purchase a Reserved Instance?ResolutionYou can purchase an EC2 Reserved Instance through the Amazon EC2 console. Note that a Reserved Instance purchase can't be canceled, so it's important to purchase the Reserved Instance that's right for your needs.Choosing the right Reserved InstanceTo get the maximum benefit from your Reserved Instance purchase, the Reserved Instance must match the attributes for running On-Demand Instances on your account. For information about the attributes that must match, see Amazon EC2 RI types.Note that Reserved Instances are not physical instances, but rather a billing discount applied to the use of On-Demand Instances in your account.For an overview of the On-Demand Instance hours you're currently using by instance type, use the Amazon EC2 usage reports in Cost Explorer. For more information, see How do I view my Reserved Instance utilization and coverage?Trusted Advisor can also recommend Reserved Instances for you based on your usage.Purchasing a Reserved Instance from the EC2 consoleIn the Amazon EC2 console, you can purchase an EC2 Reserved Instance either from AWS directly or from a third-party seller on the Reserved Instance Marketplace. Follow the instructions at How to purchase Reserved Instances.When you purchase a Reserved Instance that includes an upfront cost, your default payment method is billed immediately, with a separate invoice. The upfront payment must be charged successfully before your Reserved Instance will activate.Note: AWS credits can't be applied to the upfront costs associated with Reserved Instances. If your credits include Amazon EC2 as an applicable service, they're applied to the discounted hourly rate for any Reserved Instances.Related informationReserved InstancesAmazon EC2 Reserved InstancesBuying Reserved InstancesFollow"


Question: How can I troubleshoot the Classic Load Balancer session stickiness feature?

"I have a Classic Load Balancer with duration-based or application-controlled session stickiness. The load balancer is configured to route client HTTP or HTTPS sessions to the same registered instance, but client requests are being routed to different registered instances. How can I troubleshoot problems with Elastic Load Balancing (ELB) session stickiness?"

Answer: "I have a Classic Load Balancer with duration-based or application-controlled session stickiness. The load balancer is configured to route client HTTP or HTTPS sessions to the same registered instance, but client requests are being routed to different registered instances. How can I troubleshoot problems with Elastic Load Balancing (ELB) session stickiness?Short descriptionBy default, a Classic Load Balancer routes each request to the registered instance with the fewest outstanding requests. Using sticky sessions (session affinity) configures a load balancer to bind user sessions to a specific instance, so all requests from a user during a session are sent to the same instance. A sticky session can fail if:1.    The registered instance is not inserting an application cookie.2.    The client is not returning the cookies in the request header.3.    The cookies inserted by a registered instance are not formatted correctly.4.    The expiration period specified when using a duration-based sticky session has passed.5.    The HTTP or HTTPS request is passing through more than one load balancer that has stickiness enabled.Note: The load balancer session stickiness feature is supported only with HTTP or HTTPS listeners.ResolutionApplication-controlled session stickiness1.    Check for HTTP errors with your Classic Load Balancer. For more information, see Troubleshoot a Classic Load Balancer: HTTP Errors.2.    Run a command similar to the following to the load balancer DNS name. Check for the these two cookies in the response: An application cookie is inserted by your application running on a backend instance.An AWSELB cookie is inserted by the load balancer.Note: Before you run this command, be sure to replace the DNS name with the name of your load balancer.[ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null internal-TESTELB-1430759361.eu-central-1.elb.amazonaws.comNote: The curl utility is native to Linux, but can also be installed on Windows.The following is an example response to the command:...< Set-Cookie: PHPSESSID=k0qu6t4e35i4lgmsk78mj9k4a4; path=/< Set-Cookie: AWSELB=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/...Note: If there is no AWSELB cookie in the response, then there is no stickiness between the client and the backend instance. 3.    Verify that the registered instance is inserting an application cookie by sending an HTTP request directly to the registered instance IP by running a command similar to the following: [ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null 172.31.30.168The command returns a response similar to the following example:...< Set-Cookie: PHPSESSID=5pq74110nuir60kpapj04mglg4; path=/...4.    Verify that the cookie name generated by the registered instance is the same as the cookie name configured on the load balancer. 5.    If the registered instances insert an application cookie in their responses and the load balancer inserts an AWSELB cookie, be sure that the client sends both of these cookies in subsequent requests. If the client fails to include either the application or the AWSELB cookie, then stickiness won't work. To verify that the client sends both the application and AWSELB cookies, take a packet capture on the client or use the browser’s web-debugging tools to retrieve the cookie information in the request header.6.    If you want to know which backend instance that the load balancer routed the request to, you can configure the backend instance to display the instance ID using Instance metadata by running a script similar to the following:<?php $instance_id =file_get_contents('http://169.254.169.254/latest/meta-data/instance-id');echo "instance id = " . $instance_id . "\\xA";?>7.    Review your ELB access log to check if requests from the same user were routed to different registered instances. For more information about reviewing ELB access logs, see Access logs for your Classic Load Balancer. 8.    Verify that the cookie inserted by the application is formatted correctly for HTTP.9.    If your request is passing through multiple load balancers, verify that stickiness is enabled on only one load balancer. If more than one load balancer inserts a cookie, it replaces the original cookie and stickiness fails. Duration-based session stickiness1.    Run a command similar to the following to the load balancer DNS name to check for an AWSELB cookie in the response: [ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null internal-TESTELB-1430759361.eu-central-1.elb.amazonaws.comThe command returns a response similar to the following example:...< Set-Cookie: AWSELB=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/...Note: If there is no AWSELB cookie in the response, then there is no stickiness between the client and the backend instance.2.    If the load balancer inserts an AWSELB cookie, be sure that the client sends this cookie in subsequent requests. If the client fails to include the AWSELB cookie, then stickiness won't work. To verify that the client sends the AWSELB cookie, take a packet capture on the client or use the browser’s web-debugging tools to retrieve the cookie information in the request header.3.    Check the duration configured on the load balancer. If the cookie expiration period has passed, client sessions no longer stick to the registered instance until a new cookie is issued by the load balancer.4.    If your request is passing through multiple load balancers, verify that stickiness is enabled on only one load balancer. If more than one load balancer inserts a cookie, it replaces the original cookie and stickiness fails. Related informationConfigure sticky sessions for your Classic Load Balancerdescribe-load-balancersFollow"


Question: Why isn't my CloudWatch GetMetricStatistics API call returning data points?

"My Amazon CloudWatch "GetMetricStatistics" API call isn't returning any data points. However, the data points are available on the CloudWatch console."

Answer: "My Amazon CloudWatch "GetMetricStatistics" API call isn't returning any data points. However, the data points are available on the CloudWatch console.ResolutionNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.CloudWatch is a Regional service, so make sure that the API call uses the correct AWS Region. CloudWatch issues the GetMetricStatistics API call with multiple arguments, and those arguments must match the properties of the metric. These arguments are case sensitive, so be sure that the names and cases match in the CloudWatch console configuration. Errors are most often the result of incorrect arguments.DimensionsIf the metric is created with multiple dimensions, then you can retrieve the data points for that only if you specify all the configured dimensions. For example, suppose you publish a metric named ServerStats in the DataCenterMetric namespace with these properties:Dimensions: Server=Prod, Domain=Frankfurt, Unit: Count, Timestamp: 2016-10-31T12:30:00Z, Value: 105To retrieve data points for this metric, specify the following dimensions:Server=Prod,Domain=FrankfurtHowever, if you specify just one of the two dimensions, then you can't retrieve the data points. See the following example:Server=ProdWith the AWS CLI, the format for specifying dimensions in the get-metric-statistics command is different from the put-metric-data command. Be sure to use a format similar to the following:"Name"=string, "Value"=stringNote: In this case, a format of Name=Value is unsuccessful.See the following example of a get-metric-statistics call:aws cloudwatch get-metric-statistics --metric-name "MyMetric" --start-time 2018-04-08T23:18:00Z --end-time 2018-04-09T23:18:00Z --period 3600 --namespace "MyNamespace" --statistics Maximum --dimensions Name=Server,Value=ProdSee the following example of a put-metric-data call:aws cloudwatch put-metric-data --namespace "MyNamespace" --metric-name "MyMetric" --dimensions Server=Prod --value 10PeriodIf the metric isn't pushed for the specified period value, then no data points are returned.For example, if you activate basic monitoring for an instance, then Amazon Elastic Compute Cloud (Amazon EC2) pushes data points every five minutes. For example, suppose that Amazon EC2 pushes the data points at timestamps 12:00, 12:05, 12:10, and so on. Your start time and end time are 12:01 and 12:04, and then you try to retrieve the data points with a period of 60 seconds. In this case, you don't see any data points. It's a best practice to have your start time and end time extend beyond the minimum granularity that's offered by the metric. (For this use case, the granularity is 5 minutes.) Or, use a period that's greater than or equal to the minimum granularity that's offered by the metric.StatisticsTo retrieve percentile statistics for a metric, use ExtendedStatistic.CloudWatch uses raw data points to calculate percentiles. When you publish data using a statistic set, you can retrieve percentile statistics for this data only if one of the following conditions is true:The SampleCount of the statistic set is 1.The Min and the Max of the statistic set are equal.UnitIf the specified unit is different from the one that's configured for the metric, then no data points are returned.If you don't specify the unit argument, then data points for all units are returned.Start time and end timeFormat the start time and the end time arguments as specified in the GetMetricStatistics documentation.If no data points are pushed for the metric between the start time and end time, then no data points are returned.Note: Data points with timestamps from 24 hours ago or longer can take at least 48 hours to become available for get-metric-statistics. For more information, see put-metric-data.Related informationAWS services that publish CloudWatch metricsFollow"


Question: How am I billed for AWS Support?

"I want to sign up for a paid AWS Support plan, and I want to know how I'm charged for it."

Answer: "I want to sign up for a paid AWS Support plan, and I want to know how I'm charged for it.ResolutionWhen you sign up for a paid AWS Support plan, your payment method is charged a prorated minimum monthly service charge on your first monthly bill. If applicable, usage charges that exceed the monthly minimum charge are also billed at the end of the month. You can see your monthly charges, including your prorated charges, by expanding the Support section on your Bills page.Related informationAWS pricingAWS Support plan pricingCompare AWS Support plansAWS Support FAQsFollow"


Question: I accidentally denied everyone access to my Amazon S3 bucket. How do I regain access?

I incorrectly configured my bucket policy to deny all users access to my Amazon Simple Storage Service (Amazon S3) bucket.

Answer: "I incorrectly configured my bucket policy to deny all users access to my Amazon Simple Storage Service (Amazon S3) bucket.ResolutionConditions for the bucket policy can't be metIf the conditions for the bucket policy can't be met, then you can still regain access of your Amazon S3 bucket. To regain access to your bucket, sign in to the Amazon S3 console as the AWS account root user. Then, delete the bucket policy.Important: Don't use the root user for everyday tasks. Limit the use of these credentials to only the tasks that require you to sign in as the root user. Root credentials aren't the same as an AWS Identity Access Management (IAM) user or role with full administrator access. You can't attach IAM policies with allow or deny permissions to the root account.Sign in to the AWS Management Console as the account root user.Open the Amazon S3 console.Navigate to the incorrectly configured bucket.Choose the Permissions tab.Choose Bucket Policy.Choose Delete.On the Delete bucket policy page, enter delete into the text field to confirm the deletion of the bucket policy.Choose Delete.Sign out of the AWS Management Console.(Optional) It's a best practice for the account administrator to rotate the root user password.After the root user deletes the bucket policy, an IAM user with bucket access can apply a new bucket policy with the correct permissions. For more information, see Bucket policy examples and Adding a bucket policy by using the Amazon S3 console.Conditions for the bucket policy can be metIf you can't use the root user account, then you can delete the policy if you meet the bucket policy conditions.To regain access to your bucket, complete the following steps:Review the bucket policy to determine the conditions that are set that can be fulfilled.Take the steps to meet the bucket policy conditions.After regaining access, update the bucket policy to remove or modify the restrictive conditions to prevent future lockouts.Test the changes and make sure that the level of access control is correct.If you're unsure of the policy applied to a bucket prior to a lockout, then use AWS CloudTrail to review the event. To search for recent PutBucketPolicy actions in the account using CloudTrail, complete the following steps:Open the CloudTrail console.In the navigation pane, choose Event history.On the Event history page, under Lookup attributes, choose Event name.In the Enter an event name field, choose PutBucketPolicy and press enter.Choose the most recent event and review the details of the event. The event displays the request and response parameters. This includes the bucket name and the full bucket policy.Follow"


Question: How can I grant access to the AWS Management Console for on-premises Active Directory users?

I want to grant access to the AWS Management Console using my Active Directory domain credentials.

Answer: "I want to grant access to the AWS Management Console using my Active Directory domain credentials.Short descriptionManage Amazon Web Services (AWS) resources with AWS Identity and Access Management (IAM) role-based access to the AWS Management Console. Use either AD Connector or AWS Directory Service for Microsoft Active Directory. The IAM role defines the services, resources, and level of access that your Active Directory users have.ResolutionChoose either AD Connector or AWS Managed Microsoft ADCreate a VPN connection and configure an AD Connector between your on-premises domain with the following minimum port requirements:TCP/UDP 53 for DNSTCP/UDP 88 for Kerberos authenticationTCP/UDP 389 for LDAP authenticationFor more information, see AD Connector prerequisites.- or -Use an existing trust relationship between your on-premises domain and AWS Managed Microsoft AD with the following minimum port requirements:TCP/UDP 53 for DNSTCP/UDP 88 for Kerberos authenticationTCP/UDP 389 for LDAP authenticationTCP 445 for SMBFor more information, see Create a trust relationship between your AWS Managed Microsoft AD and your self-managed Active Directory domain.Set up authenticationCreate an access URL for the directory.Activate AWS Management Console access for your AD Connector or AWS Managed Microsoft AD.Create an IAM role that grants access to the AWS Management Console for services that you want your Active Directory users to have access to.Note: Be sure that the IAM role has a trust relationship with AWS Directory Service.Assign Active Directory users or groups to the IAM role.Verify that users can access the AWS Management Console. Open the directory access URL in a private browsing session and sign in with a user account that's assigned to the IAM role. Then, check the AWS service consoles to confirm that you're permitted or denied access to services as specified by the IAM role.Related informationCreating a role to delegate permissions to an IAM userFollow"


Question: How can I perform write operations to my Amazon RDS for MariaDB or MySQL DB instance read replica?

I want to perform both read and write operations in my Amazon Relational Database Service (Amazon RDS) for MariaDB or MySQL DB instance read replica. How can I do this?

Answer: "I want to perform both read and write operations in my Amazon Relational Database Service (Amazon RDS) for MariaDB or MySQL DB instance read replica. How can I do this?Short descriptionAmazon RDS DB instance read replicas are read-only by design. In some scenarios, you might need to configure a DB instance read replica so that the replica is modifiable.ResolutionIf you're using Amazon RDS for MySQL or MariaDB, configure a DB instance read replica to be read/write. You can do this by setting the read_only parameter to false for the DB parameter group that is associated with your DB instance. The read_only parameter can't be modified when using other Amazon RDS engines, such as Amazon Aurora.Note: Automations, such as backups, restore, and failover, are not impacted when you enable writes on the replica. But, if you perform writes without understanding the impact of the writes, this can cause inconsistency or replication failures.To configure your Amazon RDS DB instance read replica to be read/write, follow these steps:Create a DB parameter group for your MySQL or MariaDB instance.Modify the parameter group.Associate your RDS DB instance with the DB parameter group.Note: If you create a DB instance without specifying a DB parameter group, a default DB parameter group is created. This means that default parameter groups can't be modified. If you already have a custom parameter group that is associated with the instance, you don't need to create a new parameter group. For more information about DB parameter groups, see Working with parameter groups.Create a DB parameter groupOpen the Amazon RDS console.In the navigation pane, from Parameter groups, choose Create parameter group.For Parameter group family, choose the parameter group family.For Type, choose DB Parameter Group.For Group name, enter the name of the new DB parameter group.For Description, enter a description for the new DB parameter group.Choose Create.Modify the parameter groupOpen the Amazon RDS console.In the navigation pane, from Parameter groups, select the parameter group that you want to modify.Choose Parameter group actions, and then choose Edit.Edit the following parameter: read_only = 0Choose Save changes.Associate your RDS DB instance with the DB parameter groupOpen the Amazon RDS console.In the navigation pane, from Databases, select the DB instance that you want to associate with the modified DB parameter group.Choose Modify.Note: The instance status is Modifying, and the parameter group is Applying.From Database options, choose the parameter group that you want to associate with the DB instance.After the instance status is Available and the parameter group is Pending-reboot, reboot the instance without failover.Note: The parameter group name changes immediately, but changes to the parameter aren't applied until you reboot the instance without failover.Related informationOverview of Amazon RDS read replicasHow do I modify the values of an Amazon RDS DB parameter group?Follow"


Question: How do I install SSM Agent on an Amazon EC2 Linux instance at launch?

I want to install the AWS Systems Manager Agent (SSM Agent) on my Amazon Elastic Compute Cloud (Amazon EC2) Linux instance and have it start before launch.

Answer: "I want to install the AWS Systems Manager Agent (SSM Agent) on my Amazon Elastic Compute Cloud (Amazon EC2) Linux instance and have it start before launch.Short descriptionFor a list of Amazon Machine Images (AMIs) with SSM Agent preinstalled, see Amazon Machine Images (AMIs) with SSM Agent preinstalled.You must manually install SSM Agent on Amazon EC2 instances created from other versions of Linux AMIs. You can install SSM Agent by adding user data to an Amazon EC2 Linux instance before the launch. You can keep the SSM Agent up to date by activating SSM Agent auto update under Fleet Manager settings.Important: Before installing SSM Agent, make sure that the following requirements are met:AWS System Manager - Supported operating systemsSystems Manager prerequisitesResolution1.    Create an AWS Identity and Access Management (IAM) instance profile to use with SSM Agent.2.    Launch a new Amazon EC2 instance. Then, configure your instance parameters, such as application and OS images, instance type, key pair, network settings, and storage.3.    Expand the Advanced Details section. In the IAM Instance Profile dropdown list, select the instance profile that you created in step 1.4.    In the User data box, enter the following information.Amazon Linux 2023, Amazon Linux 2, RHEL 7, and CentOS 7 (64 bit)#!/bin/bashcd /tmpsudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpmsudo systemctl enable amazon-ssm-agentsudo systemctl start amazon-ssm-agentRHEL 9, RHEL 8, and CentOS 8#!/bin/bashcd /tmpsudo dnf install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpmsudo systemctl enable amazon-ssm-agentsudo systemctl start amazon-ssm-agentNote: Python 2 or Python 3 must be installed on your RHEL 9, RHEL 8 or CentOS 8 instance for SSM Agent to work correctly. To verify that Python is installed, add the following command to the preceding command examples:sudo dnf install python3Amazon Linux, CentOS 6 (64 bit)#!/bin/bashcd /tmpsudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpmsudo start amazon-ssm-agentUbuntu 22 and Ubuntu 16 (Deb Installer), Debian 8 and 9#!/bin/bashmkdir /tmp/ssmcd /tmp/ssmwget https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/debian_amd64/amazon-ssm-agent.debsudo dpkg -i amazon-ssm-agent.debsudo systemctl enable amazon-ssm-agentUbuntu 14 (Deb installer)#!/bin/bashmkdir /tmp/ssmcd /tmp/ssmwget https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/debian_amd64/amazon-ssm-agent.debsudo dpkg -i amazon-ssm-agent.debsudo start amazon-ssm-agentSuse 15, Suse 12#!/bin/bashmkdir /tmp/ssmcd /tmp/ssmwget https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpmsudo rpm --install amazon-ssm-agent.rpmsudo systemctl enable amazon-ssm-agentsudo systemctl start amazon-ssm-agentFor more information, see User data and the console.6.    Enter the number of instances to be launched.7.    Launch your instance(s).For Windows, see How do I install AWS Systems Manager Agent (SSM Agent) on an Amazon EC2 Windows instance at launch?Activate SSM Agent auto update1.    Open the AWS Systems Manager console.2.    In the navigation pane, choose Fleet Manager.3.    Choose the Settings tab, and then choose Auto update SSM Agent under Agent auto update.Note: The Auto update SSM Agent setting applies to all the managed nodes in the Region where this setting is configured.4.    Then, configure your SSM Agent fleet:To change the version of SSM Agent your fleet updates to, choose Edit under Agent auto update on the Settings tab. Then, enter the version number of SSM Agent you want to update to in Version under Parameters. If the version number isn't specified, then the agent updates to the latest version.To change the defined schedule (the default is to run every 14 days), choose Edit under Agent auto update on the Settings tab. Then, configure your preferred schedule using the On Schedule option under Specify schedule based on Cron and rate expressions for associations.To stop automatically deploying updated versions of SSM Agent to managed nodes in your account, choose Delete under Agent auto update on the Settings tab. This deletes the State Manager association that automatically updates SSM Agent on your managed nodes.Related informationAutomating updates to SSM AgentWorking with SSM Agent on EC2 instances for LinuxSetting up AWS Systems ManagerWorking with SSM Agent on EC2 instances for Windows ServerWhy is my EC2 instance not displaying as a managed node or showing a "Connection lost" status in Systems Manager?Follow"


Question: How can I configure a Site-to-Site VPN connection with dynamic routing between AWS and Microsoft Azure?

I want to configure AWS Site-to-Site VPN connectivity between AWS and Microsoft Azure with Border Gateway Protocol (BGP).

Answer: "I want to configure AWS Site-to-Site VPN connectivity between AWS and Microsoft Azure with Border Gateway Protocol (BGP).ResolutionNote: For more information on optimizing performance, see AWS Site-to-Site VPN, choosing the right options to optimize performance.PrerequisitesBefore configuring your connection, check the following:Make sure that you have an Amazon Virtual Private Cloud (Amazon VPC) CIDR associated to a virtual private gateway or attached to a transit gateway. Make sure that the Amazon VPC CIDR doesn't overlap with the Microsoft Azure network CIDR.AWS configuration1.    Create a customer gateway.2.    Verify the Autonomous System Number (ASN). You can add your own, or use the default option (65000). If you choose the default, then AWS provides an ASN for your customer gateway.3.    For Customer Gateway IP address, enter the Microsoft Azure public IP address. You're given this address when you configure the virtual network gateway in the Microsoft Azure portal. Refer to step 2 of the Microsoft Azure Configuration section in this article for more information.4.    Create an AWS Site-to-Site VPN.5.    Choose an address from the Microsoft Azure reserved APIPA address range for your Site-to-Site VPN. This is necessary because you're setting up BGP Site-to-Site VPN for Microsoft Azure and because AWS Site-to-Site VPN devices use APIPA addresses for BGP. This range is from 169.254.21.0 to 169.254.22.255 for tunnels inside the IPv4 CIDR address. See the following example:Example address: 169.254.21.0/30   BGP IP address (AWS): 169.254.21.1BGP Peer IP address (Microsoft Azure): 169.254.21.26.    For Gateway, choose either the virtual private gateway or transit gateway, and then for Routing options, choose Dynamic.7.    Choose your VPN ID, and then for Vendor choose Generic. 8.    Download the AWS configuration file.If you're building a Site-to-Site VPN connection to a transit gateway, then make sure that you have the correct transit gateway attachments. Do this for both the Amazon VPC and your Site-to-Site VPN. Also, turn on route propagation. Initially, only the Amazon VPC routes are propagated. The Microsoft Azure virtual network CIDR isn't propagated in the transit gateway route tables until BGP is established.Microsoft Azure configuration1.    Follow the instructions on the Microsoft website to create a virtual network in Microsoft Azure.2.    Follow the instructions on the Microsoft website to create a virtual network gateway with a public IP address assigned to it. Use the following details:Region: Choose the region that you want to deploy the virtual network gateway in.Gateway type: VPNVPN Type: Route-basedSKU: Choose the SKU that meets your requirements for workloads, throughputs, features, and SLAs.Virtual Network: A virtual network is associated with your virtual network gateway (similar to a VPC in the AWS environment).Enable active-active mode: Choose Disabled. This creates a new public IP address that's used as the customer gateway IP address in the AWS Management Console.Configure BGP: Choose Enabled.Custom Azure APIPA BGP IP address: (169.254.21.2).Note: The ASN that you specify for the virtual network gateway must be the same as the customer gateway ASN in the AWS Management Console (65000).3.    Follow the instructions on the Microsoft website to create a local network gateway. Use the following details:IP Address: Enter the public IP address of Tunnel 1 that you received when you created AWS Site-to-Site VPN. You can view this in the configuration file that you downloaded from the AWS Management Console.Address space: Enter the Amazon VPC CIDR block.Autonomous System Number (ASN): Enter AWS ASN.BGP peer IP address: Enter the AWS BGP IP (As seen in step 5 of AWS configuration).4.    Follow the instructions on the Microsoft website to create a Site-to-Site VPN connection in the Microsoft Azure portal with BGP turned on. Note: The cryptographic algorithms and PSK are the same on both the Microsoft Azure side and the AWS side.Phase 1 (IKE):    Encryption: AES56      Authentication: SHA256      DH Group: 14Phase 2 (IPSEC):    Encryption: AES256      Authentication: SHA256      DH Group: 14 _(PFS2048)_ Diffie-Hellmen Group used in Quick Mode or Phase 2 is the PFS Group specified in Azure.       Lifetime: 3600s (Default on Azure portal is set to 27000s. AWS supports maximum of 3600s for IPSEC lifetime)Set up Active/Active BGP failover with AWS Site-to-Site VPN between AWS and Microsoft Azure1.    Follow the instructions on the Microsoft website to create a virtual network gateway. For Enable active-active mode, choose Enabled. This provides two public IP addresses.2.    Open the AWS Site-to-Site VPN console. Use the two public IP addresses from the Microsoft Azure portal for the virtual network gateway to create two customer gateways. Use the following details:IP address: Enter the Azure public node 1 IP address for the first customer gateway and Azure public node 2 IP address for the second customer gateway.BGP ASN: Enter the ASN that you configured on the Microsoft Azure side.Routing type: Choose Dynamic.3.    In the AWS Management Console, create two Site-to-Site VPN connections that connect to either a virtual private gateway or a transit gateway. For Tunnel 1 of both Site-to-Site VPN connections, enter the following for the BGP peer IP address:Site-to-Site VPN 1: 169.254.21.0/30Site-to-Site VPN 2: 169.254.22.0/30The first IP address inside the IP /30 address is assigned to the AWS Site-to-Site VPN BGP IP address (169.254.21.1 or 69.254.22.1), and the second is assigned to the Microsoft Azure BGP IP (169.254.21.2 or 69.254.22.2).4.     Using the Microsoft Azure portal, create two Microsoft Azure local network gateways. For the IP addresses, use the Tunnel 1 public IP addresses from your AWS Site-to-Site VPN tunnels. Also, make sure that the ASN matches the virtual private gateway or transit gateway.5.    Using the Microsoft Azure portal, create two Microsoft Azure Site-to-Site VPN connections. Make sure that each connection has a Microsoft Azure virtual network gateway pointing towards the local network gateways that you created in the previous step.Turn on Transit gateway ECMP SupportFor an Active/Active setup, where two Site-to-Site VPN connections terminate on transit gateways, both Site-to-Site VPNs have a single tunnel configured. So, there are two active Site-to-Site VPN tunnels out of a possible four. When the transit gateway has ECMP Support turned on, traffic can be load balanced across both Site-to-Site VPN connections. If one Site-to-Site VPN connection goes into the DOWN status, then failover to the redundant link happens automatically through BGP.Verify VPN Connection StateAfter your Site-to-Site VPN configuration is established, check that the VPN Tunnel State is in the UP status. To do this, choose the Tunnel Details tab on the Site-to-Site VPN console.On the Microsoft Azure portal, verify the VPN connection. Confirm that the status is Succeeded, and then changes to Connected when you made a successful connection.Create an Amazon Elastic Compute Cloud (Amazon EC2) instance in your Amazon VPC to verify the connectivity between AWS and Microsoft Azure. Then, follow the instructions on the Microsoft website to connect to the Microsoft Azure VM private IP address and confirm that the Site-to-Site VPN connection is established.For more information, see Testing the Site-to-Site VPN connection and How doI check the current status of my VPN tunnel?Follow"


Question: My Lambda rotation function called a second function to rotate a Secrets Manager secret but it failed. Why did the second Lambda function fail?

My AWS Lambda function failed to rotate an AWS Secrets Manager secret for another function.

Answer: "My AWS Lambda function failed to rotate an AWS Secrets Manager secret for another function.Short descriptionIf a rotation function calls a second Lambda function to rotate the secret, the rotation fails with a message similar to the following:Pending secret version EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE for Secret MySecret was not created by Lambda MyRotationFunction. Remove the AWSPENDING staging label and restart rotation.ResolutionTo resolve this issue, make sure that the code to rotate your secret is contained in a single Lambda function that's set as the rotation function for the secret.Related informationTroubleshoot AWS Secrets Manager rotationFollow"


Question: Why do I still see charges for Amazon S3 after I deleted all the files from my Amazon S3 buckets?

"I deleted all the files from my Amazon Simple Storage Service (Amazon S3) buckets, but I still have charges for S3 on my bill."

Answer: "I deleted all the files from my Amazon Simple Storage Service (Amazon S3) buckets, but I still have charges for S3 on my bill.ResolutionHere are some things you can check to minimize your S3 charges:Disable logging for any S3 buckets before deleting them. Otherwise, logs might be immediately written to your bucket after you delete your bucket's objects.Delete any file versions (backups of S3 objects) in versioning-enabled buckets.Delete empty S3 buckets that you don't need. Some programs (including the AWS Management Console) initiate LIST requests to pull the names of your buckets. These requests are charged at standard rates.Cancel any incomplete multipart upload requests.Related informationWorking with Amazon S3 bucketsWorking with Amazon S3 objectsFollow"


Question: How can I troubleshoot AWS DMS endpoint connectivity failures?

"I can't connect to my AWS Database Migration Service (AWS DMS) endpoints. Why is my test connection failing, and how can I troubleshoot these connectivity issues?"

Answer: "I can't connect to my AWS Database Migration Service (AWS DMS) endpoints. Why is my test connection failing, and how can I troubleshoot these connectivity issues?Short descriptionThere are two types of errors typically seen when testing the connection from the replication instance to the source or target endpoint:1.    If the error occurred because of connectivity issue between replication instance and source or target, then you see errors similar to the following:"Application-Status: 1020912, Application-Message: Failed to connect Network error has occurred, Application-Detailed-Message: RetCode: SQL_ERROR SqlState: HYT00 NativeError: 0 Message: [unixODBC][Microsoft][ODBC Driver 13 for SQL Server]Login timeout expired ODBC general error.""Application-Status: 1020912, Application-Message: Cannot connect to ODBC provider Network error has occurred, Application-Detailed-Message: RetCode: SQL_ERROR SqlState: 08001 NativeError: 101 Message: [unixODBC]timeout expired ODBC general error.""Application-Status: 1020912, Application-Message: Cannot connect to ODBC provider ODBC general error., Application-Detailed-Message: RetCode: SQL_ERROR SqlState: HY000 NativeError: 2005 Message: [unixODBC][MySQL][ODBC 5.3(w) Driver]Unknown MySQL server host 'mysql1.xxxxx.us-east-1.rds.amazonaws.com' (22) ODBC general error."2.    If the error occurred because of a native database error, such as database permission or authentication error, then you see errors similar to the following:"Application-Status: 1020912, Application-Message: Cannot connect to ODBC provider Network error has occurred, Application-Detailed-Message: RetCode: SQL_ERROR SqlState: 08001 NativeError: 101 Message: [unixODBC]FATAL: password authentication failed for user "dmsuser" ODBC general error."Based on the type of error you receive and your network configuration, see the appropriate resolution section.Note: It's a best practice to test the connectivity from the AWS DMS replication instance to the endpoints after creating your AWS DMS source and target endpoints. Do this before starting the AWS DMS migration task. Otherwise, the task can fail because of connectivity issues with the endpoint.ResolutionResolve connectivity issues for AWS hosted resourcesVerify that connectivity can be established between the source or target database and the replication instance. Depending on your use case and network infrastructure, connect your source or target database to a replication instance in public subnet or private subnet. For more information, see Setting up a network for a replication instance.Note: AWS DMS versions 3.4.7 and later require that you configure AWS DMS to use VPC endpoints or to use public routes to all your source and target endpoints that interact with certain Amazon Web Services. If your DMS endpoint tests are successful on earlier versions but failing on later, see Configuring VPC endpoints as AWS DMS source and target endpoints.Check your replication instance configurationIn your replication instance, confirm that your configuration includes the following:An Outbound Rule for the IP address with the port of the source or target database in the security group. By default, the Outbound Rule of a security group allows all traffic. Security groups are stateful, so you don't need to modify the Inbound Rule from the default.An Outbound Rule for the IP address with the port of the source or target database in the network ACL. By default, the Outbound Rule of network access control list (ACL) allows all trafficAn Inbound Rule for the IP address with the ephemeral ports of the source or target database in the network ACL. By default, the Inbound Rule of a network ACL allows all traffic.Check your source or target database configurationIn your source or target database, confirm that your configuration includes the following:An Inbound Rule for the IP address of the replication instance or the CIDR of the subnet group of the replication instance with the port of the source or target database in the security group. Security groups are stateful, so you don't need to modify the Outbound Rule from the default.Note: To find the IP addresses and CIDRs, see the Determine the IP addresses and CIDR of a subnet group section.An Inbound Rule for the IP address of the replication instance or the CIDR of the subnet group of the replication instance with the port of the source or target database in the network ACL. Confirm that there is no explicit deny rule for the IP address and port allowed.An Outbound Rule for the IP address or the CIDR of the subnet group of the replication instance with ephemeral ports in the network ACL. By default, the Outbound Rule of a network ACL allows all traffic.As a best practice, configure your network to allow the CIDR of the subnet group of the replication instance. The IP address of the replication instance changes during a failover or host replacement event.Determine the IP addresses and CIDR of a subnet groupTo determine the IP addresses and CIDR of the subnet group to set up inbound and outbound rules, use the AWS DMS console or the CLI.Using the AWS console:Access the AWS DMS console.From the navigation pane, choose Replication instances.Choose the name of your replication instance.Under Details, note the Public IP address, Private IP address, and the Replication subnet group of your replication instance.Under Replication subnet group, choose the link to access the subnet group page. Note the name of each subnet in the subnet group.To verify the CIDR of each subnet access the Amazon Virtual Private Cloud (Amazon VPC) console.In the Subnets tab, search for the subnets noted in step 5. For each subnet, note the CIDR.Using the AWS CLI:Run the describe-subnets command to determine the CIDR of each subnet. For replication-instance-name, enter the name of your replication instance.aws ec2 describe-subnets --filters Name=subnet-id,Values="$(aws dms describe-replication-instances --filters "Name=replication-instance-id,Values=replication-instance-name" --query "ReplicationInstances[*].ReplicationSubnetGroup.Subnets[*].SubnetIdentifier" --output text | sed -e 's/\t/,/g')" --query "Subnets[*].{SubnetId:SubnetId,CidrBlock:CidrBlock}" --output tableRun the describe-replication-instances command to determine the IP addresses of the replication instance. For replication-instance-name, enter the name of your replication instance.aws dms describe-replication-instances --filters "Name=replication-instance-id,Values=replication-instance-name" --query "ReplicationInstances[*].{ReplicationInstancePublicIpAddresses:ReplicationInstancePublicIpAddresses,ReplicationInstancePrivateIpAddresses:ReplicationInstancePrivateIpAddresses}" --output tableResolve connectivity issues (on-premises resources)If your source or target database is hosted on-premises, then confirm the following:Check with your network administrator to confirm that the database allows incoming connections from the AWS DMS replication instance.Confirm that a firewall isn't blocking communication to the source or target database.Confirm that the DNS configuration is set up correctly. If you require DNS resolution, then use the Amazon Route 53 Resolver. For information on using an on-premises name server to resolve endpoints using the Amazon Route 53 Resolver, see  Using your own on-premises name server.-or-Create a new DMS instance through the AWS CLI to use a customer DNS name server (--dns-name-servers) to resolve DNS issues. By default, DMS instances use Amazon-provided DNS for resolutions. DMS endpoints can fail if the source or target is configured to use custom DNS. For more information, see create-replication-instance.Be sure that your Amazon EC2 instance has the same network configurations as the AWS DMS replication instance with the connectivity issues. Run the following commands on the new EC2 instance to troubleshoot network connectivity:telnet <database_IP_address_or_DNS> <port_number>nslookup <domain_name>For database_IP_address_or_DNS, use the IP address or domain name of the database specified for the DMS source or target endpoint. For port_number, use the port number of the database specified for the DMS source or target endpoint. For domain_name, use the domain name of the database specified for the DMS source or target endpoint.Resolve native database errorsTo resolve native database errors, confirm that the following endpoint configurations are set correctly:UsernamePasswordSet the ServerName to the DNS or IP of the on-premises database, or Amazon Relational Database Service (Amazon RDS) endpointPortDatabase nameNote: Don't specify a Database name for MySQL source or target.Note: If any of these fields are specified with AWS Secrets Manager, then see Using secrets to access AWS Database Migration Service endpoints.For native database errors related to the source or target database, refer to the resolution from the specific database documentation. Use the error code and the error message on the DMS console.For more information, check error, trace, alert, or other logs from the source or target database.For database access errors, confirm the permissions required by DMS for the specific source or target.For more information on encrypting connections for source and target endpoints using Secure Sockets Layer (SSL), see Using SSL with AWS Database Migration Service.Related informationHow can I troubleshoot Amazon S3 endpoint connection test failures when using AWS DMS?How can I troubleshoot connectivity failures and errors for an AWS DMS task that uses Amazon Redshift as the target endpoint?How can I troubleshoot connectivity failures between AWS DMS and a MongoDB source endpoint?Migrate an on-premises Oracle database to Amazon RDS for PostgreSQL using an Oracle bystander and AWS DMSMigrating Microsoft SQL Server databases to the AWS CloudFollow"


Question: How do I access the Kubernetes Dashboard on a custom path in Amazon EKS?

I want to access the Kubernetes dashboard on a custom path in Amazon Elastic Kubernetes Service (Amazon EKS).

Answer: "I want to access the Kubernetes dashboard on a custom path in Amazon Elastic Kubernetes Service (Amazon EKS).Short descriptionTo access the Kubernetes dashboard, you must complete the following:1.    Create or use an existing self-signed certificate, and then upload the certificate to the AWS Certificate Manager (ACM).2.    Deploy the NGINX Ingress Controller, and then expose it as a NodePort service.3.    Create an Ingress object for the Application Load Balancer Ingress Controller. Have the Ingress object forward all the requests from the Application Load Balancer to the NGINX Ingress Controller that you deploy using a manifest file.4.    Deploy the Kubernetes dashboard.5.    Create an Ingress for the NGINX Ingress Controller.Here's how the resolution works:1.    The Application Load Balancer forwards all incoming traffic to the NGINX Ingress Controller.2.    The NGINX Ingress Controller evaluates the path-pattern of the incoming request (for example, /custom-path/additionalcustompath).3.    The NGINX Ingress Controller rewrites the URL to /additionalcustompath before forwarding the request to the kubernetes-dashboard service.Note: This solution doesn't work on clusters running kubernetes versions earlier than 1.19.ResolutionCreate or use an existing self-signed certificate, and then upload the certificate to ACMIf your Application Load Balancer uses an existing ACM certificate, then skip to "Deploy the NGINX Ingress Controller and expose it as a NodePort service".Note: The following steps apply to the Amazon Linux Amazon Machine Image (AMI) release 2018.03.1.    Generate a self-signed certificate using OpenSSL:openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout kube-dash-private.key -out kube-dash-public.crtImportant: Provide a fully qualified domain for Common Name. Application Load Balancer allows only ACM certificates with fully qualified domain names to be attached to the listener 443.The output looks similar to the following:Country Name (2 letter code) [XX]:State or Province Name (full name) []:Locality Name (eg, city) [Default City]:Organization Name (eg, company) [Default Company Ltd]:Organizational Unit Name (eg, section) []:Common Name (eg, your name or your server's hostname) []:kube-dashboard.com     ==>This is importantEmail Address []:3.    Install the AWS Command Line Interface (AWS CLI) and set up the credentials.Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent AWS CLI version.4.    Upload the private key and the certificate to the ACM in your AWS Region:aws acm import-certificate --certificate fileb://kube-dash-public.crt --private-key fileb://kube-dash-private.key --region us-east-1Note: Replace us-east-1 with your AWS Region.The output looks similar to the following:{"CertificateArn": "arn:aws:acm:us-east-1:your-account:certificate/your-certificate-id"}5.    Open the ACM console, and then verify that the domain name appears in your imported ACM certificate.Note: If the domain name doesn't appear in the ACM console, it's a best practice to recreate the certificate with a valid fully qualified domain name.Deploy the NGINX Ingress Controller and expose it as a NodePort service1.    Create the namespace ingress-nginx:kubectl create ns ingress-nginx2.    Install Helm version 3.3.    Use Helm to deploy the NGINX Ingress Controller:helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginxhelm repo updatehelm install nginx ingress-nginx/ingress-nginx --namespace ingress-nginx --set controller.service.type=NodePortNote: For nginx-ingress controller to run on Fargate nodes, set allowPrivilegeEscalation: false in "nginx-ingress-nginx-controller" deploymentCreate an Ingress object for the Application Load Balancer Ingress ControllerCreate an Ingress object using a manifest file. Have the Ingress object forward all requests from the Application Load Balancer Ingress Controller to the NGINX Ingress Controller that you deployed earlier.1.    Deploy the Application Load Balancer Ingress Controller.2.    Create an Ingress object for the Application Load Balancer Ingress Controller based on the following alb-ingress.yaml file:---apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  name: "alb-ingress"  namespace: "ingress-nginx"  annotations:    alb.ingress.kubernetes.io/scheme: internet-facing    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:your-region:your-account-id:certificate/XXXX-XXXX-XXXX-XXXX-XXXXX    alb.ingress.kubernetes.io/healthcheck-path: /dashboard/    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'    alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'  labels:    app: dashboardspec:  ingressClassName: alb  rules:  - http:      paths:      - path: /        pathType: Prefix        backend:          service:            name: ssl-redirect            port:              name: use-annotation      - path: /        pathType: Prefix        backend:          service:            name: "nginx-ingress-nginx-controller"            port:              number: 80Note: Replace alb.ingress.kubernetes.io/certificate-arn with the Amazon Resource Name (ARN) of your ACM certificate. For Fargate, add "alb.ingress.kubernetes.io/target-type: ip" in annotationsThe preceding manifest file uses the following annotations:The "alb.ingress.kubernetes.io/scheme" annotation creates an internet-facing Application Load Balancer. The "alb.ingress.kubernetes.io/certificate-arn" annotation associates the ARN of your ACM certificate with the 443 listener of the Application Load Balancer. The "alb.ingress.kubernetes.io/listen-ports" annotation creates the listeners for ports 80 and 443. The "alb.ingress.kubernetes.io/actions.ssl-redirect" annotation redirects all the requests coming to ports 80 to 443. The "alb.ingress.kubernetes.io/healthcheck-path" annotation sets the health check path to /dashboard/.3.    Apply the manifest file from the preceding step 2:kubectl apply -f alb-ingress.yamlDeploy the Kubernetes dashboardTo deploy the Kubernetes dashboard, see Tutorial: Deploy the Kubernetes dashboard (web UI).Create an Ingress for the NGINX Ingress Controller1.    Create an Ingress for the NGINX Ingress Controller based on the following ingress-dashboard.yaml file:---apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  name: dashboard  namespace: kubernetes-dashboard  annotations:    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"    nginx.ingress.kubernetes.io/rewrite-target: /$2    nginx.ingress.kubernetes.io/configuration-snippet: |      rewrite ^(/dashboard)$ $1/ redirect;spec:  ingressClassName: nginx  rules:  - http:      paths:      - path: /dashboard(/|$)(.*)        pathType: Prefix        backend:          service:            name: kubernetes-dashboard            port:              number: 443Note: The "nginx.ingress.kubernetes.io/rewrite-target" annotation rewrites the URL before forwarding the request to the backend pods. In /dashboard(/|$)(.*) for path, (.*) stores the dynamic URL that's generated while accessing the Kubernetes dashboard. The "nginx.ingress.kubernetes.io/rewrite-target" annotation replaces the captured data in the URL before forwarding the request to the kubernetes-dashboard service. The "nginx.ingress.kubernetes.io/configuration-snippet" annotation rewrites the URL to add a trailing slash ("/") only if ALB-URL/dashboard is accessed.2.    Apply the manifest file ingress-dashboard.yaml:kubectl apply -f ingress-dashboard.yaml3.    Check the Application Load Balancer URL in the ADDRESS of the alb-ingress that you created earlier:kubectl get ingress alb-ingress -n ingress-nginxYou can now access the Kubernetes dashboard using ALB-URL/dashboard/. If you access ALB-URL/dashboard, then a trailing slash ("/") is automatically added to the URL.Clean up the resources that you created earlier1.    Delete the ingress for the NGINX Ingress Controller:helm uninstall nginx -n ingress-nginx2.    Delete the Kubernetes dashboard components and the Metrics Server:kubectl delete -f eks-admin-service-account.yamlkubectl delete -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta8/aio/deploy/recommended.yamlkubectl delete -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.6/components.yaml>3.    Delete the alb-ingress:kubectl delete -f alb-ingress.yamlNote: If you created AWS Identity and Access Management (IAM) resources, then you can delete the IAM role and IAM policy.4.    Delete the AWS Load Balancer Controller:helm uninstall aws-load-balancer-controller -n kube-system5.    Delete the ingress-ngix namespace:kubectl delete ns ingress-nginx6.    To delete the ACM certificate that you created, run the following command:aws acm delete-certificate \    --certificate-arn arn:aws:acm:us-east-1:your-account-id:certificate/XXXX-XXXX-XXXX-XXXX-XXXXX \    --region us-east-1Note: Replace certificate-arn with your certificate ARN. Replace us-east-1 with your AWS Region. Replace your-account-id with your account ID.Follow"


Question: Why did my publicly trusted ACM certificate fail managed renewal?

My AWS Certificate Manager (ACM) certificate failed to renew. Why didn't my ACM certificate renew?

Answer: "My AWS Certificate Manager (ACM) certificate failed to renew. Why didn't my ACM certificate renew?Short descriptionACM provides managed renewal for your AWS issued SSL/TLS certificates. This means that ACM either renews your certificates automatically if you are using DNS validation, or sends you an email notification when expiration is approaching. ACM tries to validate each domain name included in the certificate. After all domain names associated with the certificate are validated, the ACM certificate is renewed. For more information, see Troubleshooting managed certificate renewal.Managed renewal can fail for email and DNS validated certificates if:The certificate was imported into ACM. Imported certificates aren't renewed automatically.The ACM certificate that's being renewed is not in use—the ACM certificate isn't associated with any of the services integrated with ACM.Renewal for domains validated by email require manual action. ACM begins sending email renewal notices 45 days before expiration using the domain's WHOIS mailbox addresses and to five common administrator addresses. The notifications contain a link that the domain owner can select for renewal. After all listed domains are validated, ACM issues a renewed certificate with the same ARN.Managed renewal for domains validated by DNS can fail if ACM was unable to find the appropriate CNAME record in the DNS database.ResolutionEmail and DNS validated certificatesBe sure that the ACM certificate is in use with one of the services integrated with ACM.Email validated certificatesFor email-validated certificates, ACM must be able to send to the WHOIS mailbox addresses and the five common administrator addresses for each domain listed in your certificate. After all listed domains are validated, ACM issues a renewed certificate with the same ARN. For more information, see Email validation.DNS validated certificatesUpdate your DNS configuration to include the CNAME records provided by ACM. ACM looks for the CNAME record in the DNS configuration for the domain names included in the DNS-validated certificates.After the certificate is renewed, the Amazon Resource Name (ARN) of the renewed ACM certificate remains the same. Renewed ACM certificates are automatically updated to the integrated, in-use AWS resources.For more information, see Troubleshooting managed certificate renewal.Related informationACM best practicesHow does the ACM managed renewal process work with email-validated certificates?Check a certificate's renewal statusFollow"


Question: How do I resolve SQL exception errors with custom SQL data sources in QuickSight?

"I'm trying to use custom SQL data sources in Amazon QuickSight, but I get the error message "Your database generated a SQL exception." How do I resolve this?"

Answer: "I'm trying to use custom SQL data sources in Amazon QuickSight, but I get the error message "Your database generated a SQL exception." How do I resolve this?Short descriptionYou receive the following error message when Amazon QuickSight is querying or refreshing your SQL data source:"Your database generated a SQL exception. This can be caused by query timeouts, resource constraints, unexpected DDL alterations before or during a query, and other database errors. Check your database settings and your query, and try again."For more detailed information on what caused the error, choose Show Details under the error message.Common reasons for receiving the error message include:The query times out.There's an issue with the VPC connection to your data source.Your QuickSight account doesn't have permission to access the data.Your QuickSight service role doesn't have permission to access the AWS managed Key Management Service (AWS KMS) key.You're using unsupported data types or functions.ResolutionIf you receive errors when running AWS Command Line Interface (AWS CLI) commands,make sure that you’re using the most recent AWS CLI version.The query times outIf the custom SQL query times out, simplify the query to optimize runtime. For other query timeout solutions, see How do I resolve query timeout issues in QuickSight?There's an issue with the VPC connection to your data sourceThe details of your error message include the following:Communications link failure The last packet successfully received from the server was nnnn milliseconds ago. The last packet sent successfully to the server was nnnn milliseconds ago.-or-Communications link failure The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.If you're experiencing VPC connection issues to your data sources, check the network security group in the VPC that's associated with the resource. For more information see, Connecting to a VPC with Amazon QuickSight.Your QuickSight account doesn't have permission to access the dataIf you experience an SQL exception error when trying to access data in an AWS service, check your QuickSight security and permissions settings.Open the Amazon QuickSight console.Choose Manage QuickSight.Choose Security & Permissions.Configure access to the supported services that you use.If you use AWS Organizations, you can receive the error when you don't have the necessary service control policies (SCPs) assigned to you. Ask the AWS Organizations administrator to check your SCP settings to verify the permissions that are assigned to you. If you're an AWS Organizations administrator, see Creating, updating, and deleting service control policies.Your QuickSight service role doesn't have permission to access the AWS managed KMS keyYou receive the following error:If you are encrypting query results with KMS key, please ensure you are allowed to access your KMS key.Make sure that the QuickSight service role has the correct AWS KMS key permissions.Use the AWS Identity and Access Management (IAM) console to locate the QuickSight service role ARN.Use the Amazon Simple Storage Service (Amazon S3) console to find the AWS KMS key ARN.Go to the bucket that contains your data file.Choose the Overview tab, and locate KMS key ID.Add the QuickSight service role ARN to the KMS key policy.Run the AWS CLI create-grant command:aws kms create-grant —key-id aws_kms_key_arn —grantee-principal quicksight_role_arn —operations DecryptNote: Replace aws_kms_key_arn with the ARN of your AWS KMS key and quicksight_role_arn with the ARN of your QuickSight service role.You're using unsupported data types or functionsIf you try to import an unsupported data type or use an unsupported SQL function, you receive an SQL exception error. To resolve this issue, check the SQL data source to determine if the data type or SQL function is supported.To see what's supported, check the following resources:Supported data types from other data sourcesSupported data types and valuesFunctions by categoryRelated informationQuotas for direct SQL queriesHow can I create a private connection from Amazon QuickSight to an Amazon Redshift cluster or an Amazon Relational Database Service (Amazon RDS) DB instance that's in a private subnet?Actions, resources, and condition keys for Amazon QuickSightFollow"


Question: Why is it taking a long time to replicate Amazon S3 objects using Cross-Region Replication between my buckets?

I'm using Cross-Region Replication between two Amazon Simple Storage Service (Amazon S3) buckets in different AWS Regions. Why is object replication taking longer than I expect?

Answer: "I'm using Cross-Region Replication between two Amazon Simple Storage Service (Amazon S3) buckets in different AWS Regions. Why is object replication taking longer than I expect?ResolutionCross-Region Replication is an asynchronous process, and the objects are eventually replicated. Most objects replicate within 15 minutes, but sometimes replication can take a couple hours or more. There are several factors that can affect the replication time, including:The size of the objects to replicate.The number of objects to replicate. For example, if Amazon S3 is replicating more than 3,500 objects per second, then there might be some latency while the destination bucket scales up for the request rate.You can check the replication status on the source object. If the object replication status is PENDING, then Amazon S3 hasn't completed the replication.Note: To monitor replication metrics such as the maximum replication time to the destination bucket, you can enable S3 Replication Time Control (S3 RTC).Follow"


Question: How can I copy existing Lightsail firewall rules to different Lightsail instances?

How do I copy firewall rules to multiple Amazon Lightsail instances?

Answer: "How do I copy firewall rules to multiple Amazon Lightsail instances?Short descriptionFirewall rules are unique to each Lightsail instance. If you want multiple instances to have the same rules, you must edit the rules for each of the instances. You can use the AWS Command Line Interface (AWS CLI) and API calls to retrieve the current firewall rules, and then output them into a .json file. You can use the .json file to copy all the rules into another Lightsail instance.Note: You must install and configure the AWS CLI to perform the following resolution steps. If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI. You can also use AWS CloudShell to perform these steps.Resolution1.    Run the following command to retrieve the current configurations you want to copy from the existing instance, and then output it to a .json file. This generates a .json file containing the firewall configuration. In the following example, replace SourceInstanceName and RegionName with the correct information for your instance.$ aws lightsail get-instance-port-states --instance-name SourceInstanceName --region RegionName | grep -v "state" > firewall.json2.    Open the .json file, firewall.json in this example, and then replace "portStates" with "portInfos". This parameter is at the beginning of the file, as shown in the following example:{    "portStates": [        {            "fromPort": 80,            "toPort": 80,            "protocol": "tcp",            "cidrs": [                "0.0.0.0/0"            ],            "cidrListAliases": []        },        {            "fromPort": 22,            "toPort": 22,            "protocol": "tcp",            "cidrs": [                "0.0.0.0/0"            ],            "cidrListAliases": []        },        {            "fromPort": 8080,            "toPort": 8080,            "protocol": "tcp",            "cidrs": [                "11.11.11.0/20",                "22.22.22.0/20"            ],            "cidrListAliases": []        }    ]}3.    After changing the parameter to "portInfos", you can use the .json file to add the same configurations to other instances. In the following example, replace DestinationInstanceName, firewall.json, and RegionName with the correct information for your instance.$ aws lightsail put-instance-public-ports --instance-name DestinationInstanceName  --cli-input-json file://firewall.json --region RegionNameRelated informationAWS CLI Command Reference - lightsailAmazon Lightsail API Reference - Actionsget-instance-port-statesopen-instance-public-portsFollow"


Question: How can I troubleshoot Lambda Kinesis Firehose integration issues?

"I've integrated AWS Lambda with Amazon Kinesis Data Firehose to transform incoming source data and deliver the transformed data to destinations. However, the Lambda function didn't invoke or failed."

Answer: "I've integrated AWS Lambda with Amazon Kinesis Data Firehose to transform incoming source data and deliver the transformed data to destinations. However, the Lambda function didn't invoke or failed.Short descriptionLambda functions configured with Amazon Kinesis Data Firehose might fail due to:Insufficient AWS Identity and Access Management (IAM) permissionsLambda duration exceeding the maximum allowed timeoutLambda throttlingData transformation errorsLambda function errorsNote: If your Lambda function invocation has a network timeout or fails because you reached the invocation limit, Kinesis Data Firehose retries the invocation three times. For more information, see Data transformation failure handling.ResolutionIf you haven't already done so, turn on Amazon CloudWatch logging for your Kinesis Data Firehose. You can view the specific error logs when the Lambda invocation for data transformation or data delivery fails. You can turn on Kinesis Data Firehose error logging when you create your delivery stream. The format of the log group name is /aws/kinesisfirehose/delivery-stream-name. The delivery-stream-name is the name of the delivery stream.To identify why the Lambda function failed, check the Amazon CloudWatch Logs group for /aws/lambda/lambda-function-name. Failed data transformation records are delivered to the Amazon Simple Storage Service (Amazon S3) bucket as a backup in the processing-failed folder. The records in your S3 bucket also contain the error message for failed invocation. For more information about resolving Lambda invocation failures, see Data transformation failure handling.Insufficient IAM permissions"AssumeRoleAccessDenied - Access was denied. Ensure that the trust policy for the provided IAM role allows Kinesis Data Firehose to assume the role."This error occurs when the Amazon Kinesis Data Firehose IAM role isn't allowed to assume “firehose.amazonaws.com". Make sure that the IAM trust policy has permissions to assume “firehose.amazonaws.com" similar to the following:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "",      "Effect": "Allow",      "Principal": {        "Service": "firehose.amazonaws.com"      },     "Action": "sts:AssumeRole"    }  ]}"InvokeAccessDenied - Access was denied. Ensure that the access policy allows access to the Lambda function."This error occurs when the Amazon Kinesis Data Firehose IAM role isn't allowed permission to invoke the Lambda function used for data transformation. Make sure that the IAM policy allows Amazon Kinesis Data Firehose to invoke the Lambda function similar to the following:Note: Replace the resource ARN in this example with your variables.{  "Effect": "Allow",  "Action": [    "lambda:InvokeFunction",    "lambda:GetFunctionConfiguration"  ],  "Resource": [    "arn:aws:lambda:region:account-id:function:function-name:function-version"  ]}Lambda duration exceeding the maximum allowed timeout"Firehose encountered timeout errors when calling AWS Lambda. The maximum supported function timeout is 5 minutes."This error occurs when the Lambda function takes more than 5 minutes to complete. To troubleshoot Lambda function timeout errors with Kinesis Data Firehose, see Data transformation failure handling.Lambda throttling"InvokeLimitExceeded - The Lambda concurrent execution limit is exceeded. Increase the concurrent execution limit."This error occurs when the Lambda concurrent execution limit is exceeded. Review the Lambda concurrency metrics in the CloudWatch logs to determine your usage. To request an increase for concurrent executions, see Requesting a quota increase.For more information, see Lambda function scaling and How do I troubleshoot Lambda function throttling with "Rate exceeded" and 429 "TooManyRequestsException" errors?Data transformation errors"JsonProcessingException - There was an error parsing returned records from the Lambda function. Ensure that the returned records follow the status model required by Kinesis Data Firehose."This error occurs when the transformed records returned by Lambda aren't in the required format. All transformed records returned from Lambda must contain the parameters recordId, result, and data. Check the Lambda function code and CloudWatch logs to verify that these records contain these parameters.Note: To intentionally drop a record, set the value to Dropped.For more information, see Data transformation and status model."DuplicatedRecordId - Multiple records were returned with the same record ID. Ensure that the Lambda function returns unique record IDs for each record."This error occurs if multiple transformed records returned by the Lambda function to Kinesis Firehose have the same record ID. The record ID is passed from Kinesis Data Firehose to Lambda during the function invocation. Check the Lambda function code and CloudWatch logs to verify that each record ID is unique.Lambda function errors"The Lambda function was successfully invoked but it returned an error result."This error occurs when Amazon Kinesis Data Firehose was able to successfully invoke the Lambda function but the Lambda function execution failed due to an error. Check the data transformation CloudWatch metrics to confirm that Kinesis Data Firehose has invoked your function.If Kinesis Data Firehose hasn't invoked your Lambda function, then check the invocation time to see if it's beyond the timeout parameter. Your Lambda function might require a greater timeout value or need more memory to complete. For more information about invocation metrics, see Invocation metrics."Exceeded maximum allowed payload size” or “LAMBDA_RUNTIME Failed to post handler success response. Http response code: 413."Amazon Kinesis Data Firehose invokes a Lambda function synchronously and the invocation payload limit is 6 MB for each request and response. The Lambda payload limit is a hard limit and can't be increased. Make sure that the buffer size doesn't exceed 6 MB for each request and response.For more information, see Lambda quotas.Related informationWhy am I experiencing a data delivery failure with Kinesis Data Firehose?Follow"


Question: How do I turn on and configure enhanced networking on my EC2 instances?

"I'm running an Amazon Elastic Compute Cloud (Amazon EC2) instance, and I want to turn on enhanced networking."

Answer: "I'm running an Amazon Elastic Compute Cloud (Amazon EC2) instance, and I want to turn on enhanced networking.Short descriptionAmazon EC2 instances have three different virtual network adapters: VIF, Intel 82599 VF, and Elastic Network Adapter (ENA). For the latest instance types and adapters, see Enhanced networking on Linux and Enable enhanced networking with the Intel 82599 VF interface on Windows instances.Important:If your PPS rate reached its ceiling, then you probably reached the upper limits of the virtual network interface driver. Move to enhanced networking.If your throughput is near or exceeding 20 K PPS on the VIF driver, then it's a best practice to use enhanced networking.Use a cluster placement group to provide the lowest latency and highest PPS network performance for your instances.To reach speeds up to 10 Gbps between instances, launch your instances in a cluster placement group with the enhanced networking instance type. These instance types are placed physically close to each other. Instance types that are close to each other further reduces latency and improves transfer speeds.To reach speeds up to 25 Gbps between instances, launch your instances in a cluster placement group with ENA compatible instances. Then, make sure that traffic has multiple flows between the instances.ResolutionLinuxFollow the guide that's applicable to your instance and adapter type:Enable enhanced networking with the Intel 82599 VF interface on Linux instancesEnable enhanced networking with the Elastic Network Adapter (ENA) on Linux instancesAfter you turn on the enhanced networking driver for your instance type, perform network or kernel tuning. The default network kernel parameters are sufficient for most workloads. However, depending on the workload, adjust your configurations to optimize the throughput.It's a best practice to tune the kernel based on observable behavior and metrics. When possible, use your operating system or application guidance resources.WindowsFor information on enhanced networking, see Enhanced networking on Windows. The elastic network interface driver is installed on all Amazon AMIs for Windows Server 2008 R2 and newer.For information on elastic network interfaces, see Enable enhanced networking with the Elastic Network Adapter (ENA) on Windows instances.Related informationHow can I improve networking performance on my Amazon EC2 Windows instance?How do I benchmark network throughput between Amazon EC2 Linux instances in the same Amazon VPC?Amazon EC2 instance typesElastic Network Adapter – High performance network interface for Amazon EC2Amazon EC2 instance network bandwidthFollow"


Question: How do I change the number of open shards in Kinesis Data Streams?

I'm trying to change the number of open shards in Amazon Kinesis Data Streams. How can I do that and what do I do after resharding?

Answer: "I'm trying to change the number of open shards in Amazon Kinesis Data Streams. How can I do that and what do I do after resharding?Short DescriptionA shard can be in an OPEN, CLOSED, or EXPIRED state. When a shard is in the OPEN state, you can add and retrieve data records from the shard.To change the number of open shards in Kinesis Data Streams, do one of the following:Update the number of total shards. This changes the number of shards in the stream.Split a single shard.Merge two shards into one shard.Note: If you change the number of open shards in your Amazon Kinesis data stream, consider its impact on parent shards and hash key range values.ResolutionUpdate the number of total shardsYou can update the number of open shards using the Kinesis console or API operations. When you use the AWS Management Console, Data Streams reshards your stream by using the UpdateShardCount API.This API operation updates the shard count of the specified stream to the specified number of shards (by splitting or merging the individual shards in the background). It is a stream-level API call.It only supports uniform scaling, which creates shards of equal percentage for the hash key range.The UpdateShardCount operation readjusts the number of shards to a specific target value that is of equal sizes.Split a single shardConsider splitting a shard into two shards if you encounter a "hot" or "cold" shard.Note: You can only split or merge shards through API operations.Shards that receive more data than expected are known as “hot” shards. You can then selectively split the hot shards by using the SplitShard API to increase capacity for the hash keys that target those shards. For more information about managing hot shards, see Strategies for resharding.You can also monitor the Amazon Kinesis Data Streams Service with Amazon CloudWatch. Use CloudWatch metrics to determine "hot" or "cold" shards by enabling shard-level metrics, such as IncomingRecords and IncomingBytes.Merge two shards into one shardConsider merging two shards into one if you encounter a "hot" or "cold" shard.Note: You can only split or merge shards through API operations.Shards that receive much less data than expected are known as “cold” shards. You can then merge cold shards by using MergeShards API to use their full capacity. This is a shard-level API call. Note that you can only merge two adjacent shards, where the union of their hash key ranges forms a contiguous set without any gaps.You can also monitor the Amazon Kinesis Data Streams Service with Amazon CloudWatch. Use CloudWatch metrics to determine "hot" or "cold" shards by enabling shard-level metrics, such as IncomingRecords and IncomingBytes.Additional considerationsThe shard or pair of shards that the resharding operation acts on are known as parent shards. The shards that are created after the resharding operation are known as child shards. A parent shard also transitions from an OPEN state to a CLOSED state (and eventually, to an EXPIRED state, after the stream’s retention period). This can result in child shards being assigned an OPEN state. For more information about the parent shard transitions, see Data routing, data persistence, and shard state after a reshard.After resharding, you should also continue to read data from the CLOSED shards until they are exhausted. This helps to preserve the order of the data read by the consumer applications. After you have exhausted all of the CLOSED shards, you can begin to read data from open child shards. The Amazon Kinesis client library (KCL) is designed to adapt to resharding operations. Any data that existed in the shards before resharding is processed first. For more information about resharding operations, see Resharding, scaling, and parallel processing.If you change the number of open shards, it can also result in changes to the hash key ranges for some (or all) shards. A hash key range is the range of possible hash key values for a shard. It is a set of ordered contiguous positive integers. The range consists of starting and ending key values. For example, if you create a Kinesis data stream with five open shards, then the hash key range is divided equally by 20%. Therefore, all the shards have 20% as the hash keyspace value.If you perform resharding operations on the Kinesis data stream, the hash key range is divided among the child shards like this:Using the console or UpdateShardCount API: If you change the number of open shards from 5 to 10, then the resulting child shards now have a hash keyspace of 10%. The hash key range is divided equally into all of the open shards with a value of 10%.Using SplitShard API: Split the last shard (Shard-5) into two shards (Shard-6 and Shard-7). Before splitting a shard, the parent shard (Shard-5) had a hash keyspace of 20%. After splitting, the resultant child shards (Shard-6 and Shard-7) now have a hash keyspace of 10%. The hash key range for the parent shards is divided equally into both of the child shards with a value of 10%. Therefore, the hash keyspace is split 20%-20%-20%-20%-10%-10%.Using MergeShards API: Merge the last two shards (Shard-4 and Shard-5) into one shard (Shard-6). The parent shards (Shard-4 and Shard-5) have a hash keyspace of 20%. After merging, the resulting child shard (Shard-6) now has a hash keyspace of 40%. The hash key range of the parent shards is added to both of the child shards to equal 40%. Therefore, the hash keyspace is split 20%-20%-20%-40%.Follow"


Question: Why can't I terminate my Amazon EC2 instance?

I want to terminate my Amazon Elastic Compute Cloud (Amazon EC2) instance.

Answer: "I want to terminate my Amazon Elastic Compute Cloud (Amazon EC2) instance.Short descriptionYour EC2 instance might not terminate for the following reasons:The instance is in the stopping or pending state.Termination protection is turned on for the instance.There are incorrect permissions on the AWS Identity and Access Management (IAM) policy attached to the role or user attempting to terminate the instance.The instances is part of an Auto Scaling group.ResolutionThe instance is in the stopping or pending stateIf the instance appears to be "stuck" in the stopping state, then see Troubleshoot stopping your instance. After you stop the instance, you can then terminate it.The instance might remain in the pending state for more than 30 minutes after you attempt to launch it. If it does, then use the AWS Command Line Interface (AWS CLI) to stop the instance. In the AWS CLI, run the stop-instances command with a --force option or run the terminate-instances commandNote: If you receive errors when running AWS CLI commands, make sure that you're using the most recent version of the AWS CLI.Termination protection is turned on for the instanceIf termination protection is turned on, then you can't terminate the instance. For information on turning off termination protection on your instance, see Enable termination protection. Follow the instructions in To disable termination protection for a running or stopped instance.There are incorrect permissions on the IAM policy attached to the role or user attempting to terminate the instanceThe IAM policy attached to the role or user attempting to terminate the instance must allow the ec2:TerminateInstances API. For information on editing IAM policies, see Editing IAM policies.The instance is a part of an Auto Scaling groupIf the terminated instance is a part of an Auto Scaling group, then a replacement instance will be launched by the Auto Scaling group. This is done to maintain the desired count and is an expected behavior of the Auto Scaling group. In the AWS CLI, run the terminate-instance-in-auto-scaling-group command to terminate the instance.Follow"