Question: How do I troubleshoot HTTP 404 (Not Found) errors in CloudFront?

"My Amazon CloudFront distribution is returning HTTP 404 (Not Found) errors. Why is this happening, and how do I troubleshoot the issue?"

Answer: "My Amazon CloudFront distribution is returning HTTP 404 (Not Found) errors. Why is this happening, and how do I troubleshoot the issue?Short descriptionIf the requested file isn't present in the origin configured on the CloudFront distribution, the origin returns an HTTP 404 (Not Found) status code. CloudFront then returns the status code to the viewer.ResolutionTo troubleshoot HTTP 404 (Not Found) errors in CloudFront, verify the following:1.    The requested file is present in the origin.2.    The request URL's path matches the file path in the origin.Important: Make sure that the request URL's path includes the entire file path, including the object name. You can use an edge function to attach the full file path to the request before the request is forwarded to the origin.3.    (For distributions that use edge functions) The function is modifying the request URL path correctly. To verify, review your Lambda@Edge logs or CloudFront Functions logs.4.    (For distributions with multiple origins) The request is being sent to the correct origin. To verify, review the path patterns specified in your distribution's Cache behavior settings. Then, make sure that the request URL matches the intended path pattern.Important: CloudFront path patterns and references to objects in Amazon Simple Storage Service (Amazon S3) are case sensitive.Follow"


Question: How do I troubleshoot Remote Desktop Connection issues to my Amazon EC2 Windows instance?

I can't connect to my Amazon Elastic Compute Cloud (Amazon EC2) Windows instance with Remote Desktop Protocol (RDP). How can I fix this?

Answer: "I can't connect to my Amazon Elastic Compute Cloud (Amazon EC2) Windows instance with Remote Desktop Protocol (RDP). How can I fix this?ResolutionTroubleshoot the error message "An internal error occurred"If you receive the RDP error message "An internal error occurred", then see Step: 1 Check the RDP port on the Microsoft website.Troubleshoot using an instance screenshotYou can view an instance screenshot for visibility into the instance's status. If the screenshot indicates that the instance operating system (OS) boots successfully but fails instance status checks, then complete the following steps:Create a secondary network interface.Attach the secondary network interface to the instance.Test connecting to the instance through RDP again.Verify that you're using the correct IP addressIf the instance is in a subnet that uses a NAT Gateway, make sure that you're connecting to the instance's private IP address. The instance is unreachable on the public IP address behind the NAT Gateway.Verify that port 3389 isn't blockedVerify that port 3389 isn't blocked by your AWS security group, network ACL, OS firewall, or antivirus software.Confirm you're using the correct firewall and network configuration1.    Open a PowerShell window from your local device, and then run the following command:Test-NetConnection -ComputerName yourdomain.exampleco.com -Port 33892.    In the output of the preceding command, verify that TcpTestSucceeded is True. This indicates that the EC2 instance is responding over the network and you can reach the required RDP port. For more information, see Test-NetConnection on the Microsoft website.Additional troubleshootingIf the preceding steps don't resolve the issue, use the  AWSSupport-TroubleshootRDP automation document with AWS Systems Manager to troubleshoot and fix common RDP-related connection issues. You can run the automation document without installing the SSM agent on your instance. Also, the instance doesn't need to be managed by AWS Systems Manager to run the automation document.For manual troubleshooting steps, see Remote Desktop can't connect to the remote computer.Related informationTroubleshoot EC2 Windows instancesHow can I use EC2Rescue to troubleshoot issues with my Amazon EC2 Windows instance?Connect to your Windows instanceFollow"


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

I encounter HTTP 502 errors with my Application Load Balancer.

Answer: "I encounter HTTP 502 errors with my Application Load Balancer.Short descriptionThere are several possible causes for HTTP 502: bad gateway errors, and the source can be either from your target or your Application Load Balancer. To identify the source of the error, use Amazon CloudWatch metrics and access logs.Before you troubleshoot the error from your Application Load Balancer, make sure that you turn on access logging. To understand what each field means in the access log, see Access log entries.If the target is an AWS Lambda function, then see Troubleshoot HTTP 502 errors when the target is a Lambda function in the Resolution section.ResolutionFind the source of the HTTP 502 errorsUsing CloudWatch metricsIf data points appear under the HTTPCode_ELB_502_Count metric, then your load balancer is the source of the HTTP 502 errors. If they appear under the HTTPCode_Target_5XX_Count metric, then your target is the source.Using access logsIf the elb_status_code is "502" and the target_status_code is "-", then your load balancer is the source of the HTTP 502 errors. If the elb_status_code is "502" and the target_status_code is "502", then your target is the source of the errors.Troubleshoot HTTP 502 errorsNote: Filter the access logs by elb_status_code = "502" and target_status_code to help you determine the cause. Then, complete the relevant steps for your use case.The load balancer received a TCP RST from the target when attempting to establish a connectionIf you receive a TCP RST from the target when establishing a connection, then the load balancer can't establish a TCP 3-way handshake with the target. As a result, the load balancer can't forward the user request to the target.Check if there are data points for the TargetConnectionErrorCount metric. This metric represents the number of connections that aren't successfully established between the load balancer and the target.Check if the request_processing_time, target_processing_time, and response_processing_time, fields in the access logs are each set to value -1. This value means that the load balancer can't dispatch the request to the target because it needs a successful connection.The following is an example of an access log entry:http 2022-04-15T16:52:50.757968Z app/my-loadbalancer/50dc6c495c0c9188 192.168.131.39:2817 10.0.0.1:80 -1 -1 -1 502 - 86 155 "GET http://example.com:80/ HTTP/1.1" "curl/7.51.0" - - arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067" Root=1-58337262-36d228ad5d99923122bbe354"Note: In this access log entry, the request_processing_time, target_processing_time and response_processing_time are each set to -1.The load balancer received an unexpected response from the target, such as "ICMP Destination unreachable (Host unreachable)", when attempting to establish a connectionCheck if the request_processing_time, target_processing_time and response_processing_time fields in the access logs are all set to value -1.Check if traffic is allowed from the load balancer subnets to the targets on the target port.The target closed the connection with a TCP RST or a TCP FIN while the load balancer had an outstanding request to the targetThe load balancer receives a request and forwards it to the target. The target receives the request and starts to process it, but closes the connection to the load balancer too early. This usually occurs when the duration of the keep-alive timeout for the target is shorter than the idle timeout value of the load balancer. Make sure that the duration of the keep-alive timeout is greater than the idle timeout value.Check the values for the request_processing_time, target_processing_time and response_processing_time fields.See the following example access log entry:http 2022-04-15T16:52:50.757968Z app/my-loadbalancer/50dc6c495c0c9188 192.168.131.39:2817 10.0.0.1:80 0.001 4.205 -1 502 - 94 326 "GET http://example.com:80 HTTP/1.1" "curl/7.51.0" - - arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067 "Root=1-58337262-36d228ad5d99923122bbe354"Note: In this access log entry, the request_processing_time is 0.001, the target_processing_time is 4.205, and the response_processing_time is -1.The target response is malformed or contains HTTP headers that aren't validPerform a packet capture on the target for the timeframe of the issue to understand the target response.The load balancer encountered an SSL handshake error or SSL handshake timeout (10 seconds) when connecting to a targetThe TCP connection from the load balancer to the target's HTTPS listener is successful, but the subsequent SSL handshake times out. As a result, the load balancer can't forward the request to the target.Check if the target group uses the HTTPS protocol. If it doesn't use HTTPS protocol, then the SSL handshake timeout isn't the cause of the issue. If the target group is using the HTTPS protocol, then check the following points:Check if the request_processing_time, target_processing_time and response_processing_time fields in the access logs are all set to value -1.Check if there are data points for the TargetTLSNegotiationErrorCount metric.Perform a packet capture on the target for the timeframe of the issue to validate that it's related to an SSL handshake. If it is, then complete the steps in Perform a packet capture section.Check if the ciphers or protocols are mismatched.The deregistration delay period elapsed for a request that's handled by a target that was deregisteredIn your CloudTrail events, check for an API call with the DeregisterTargets action during the timeframe of the issue. If an API call with DeregisterTargets happened during the timeframe of the issue, then the error is caused by a target that was deregistered too early. To resolve this issue, increase the deregistration delay period so that lengthy operations can complete without failing.Troubleshoot the HTTP 502 errors when the target is a Lambda functionNote: For requests to a Lambda function that fail, the load balancer stores Lambda-specific error reason codes in the error_reason field of the access logs.The target is a Lambda function, and the response body exceeds 1 MBCheck if there's a data point for the LambdaUserError metric.Check if the error_reason field in the load balancer access log is set to LambdaResponseTooLarge.The target is a Lambda function that didn't respond before its configured timeout was reachedCheck the Lambda function timeout configuration.Check if there's a data point for the LambdaUserError metric.Check if the error_reason field in the load balancer access log is set to LambdaUnhandled.The target is a Lambda function that returned an error, or the function was throttled by the Lambda serviceContact AWS Support for guidance on service throttling.Perform a packet captureFor Linux, use the following command:sudo tcpdump -i any -w filename.pcapFor Microsoft Windows, download and use the Wireshark application (from the Wireshark website).For more details, see How do I troubleshoot network performance issues between EC2 Linux or Windows instances in a VPC and an on-premises host over the internet gateway? Refer to the Test packet capture samples using tcpdump and Take a packet capture sections.Follow"


Question: How can I schedule queries for an Amazon Redshift cluster?

I am trying to schedule a query to run in an Amazon Redshift cluster. How can I do that?

Answer: "I am trying to schedule a query to run in an Amazon Redshift cluster. How can I do that?Short descriptionYou can use the query editor to run, view, save, and schedule SQL queries for your provisioned Amazon Redshift clusters. Scheduled queries are initiated by Amazon EventBridge.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.Query editor permissionsTo use the query editor, users must have a minimum set of permissions to Amazon Redshift. If your cluster uses other AWS services, users must also have permissions to those services. For example, AWS Secrets Manager secrets and AWS Key Management Service (AWS KMS) keys. For more information, see Permissions required to use the Amazon Redshift console query editor.You can use AWS Identity and Access Management (IAM) managed policies to manage permissions based on IAM roles. For more information, see AWS managed (predefined) policies for Amazon Redshift.To schedule queries, the IAM user and role associated with the query must have permission to manage the query editor. For instructions, see Setting up permissions to schedule a query on the Amazon Redshift console.Scheduling queries using the AWS Management ConsoleTo schedule the query using the AWS Management Console, follow these steps:Note:You must use the query editor v1 to schedule queries.You can use this query editor only with provisioned clusters.1.    Open the Amazon Redshift console.2.    In the navigation pane, choose Query editor.3.    Follow the instructions to connect to a database in your cluster.4.    Follow the instructions to create a schedule to run a SQL statement.5.    If you're using AWS Secrets Manager with Amazon Redshift, then choose your secret.6.    If you're using temporary IAM user credentials, choose your cluster and provide the database and user names. Note: GetClusterCredentials permission must be present for the IAM user to use the temporary credentials.7.    Choose Save.Note: If you turned on Simple Notification Service (Amazon SNS), then make sure that the "sns:Publish" API action is present for "events.amazonaws.com". To confirm, add the following statement:{  "Sid": "Allow_Publish_Events",  "Effect": "Allow",  "Principal": {    "Service": "events.amazonaws.com"  },  "Action": "sns:Publish",  "Resource": "arn:aws:sns:us-east-1:{ACCOUNT_ID}:{SNS_TOPIC_NAME}"}Scheduling queries using a SQL statement with EventBridgeYou can schedule SQL statements using EventBridge and the Amazon Redshift data API. In the following example, a schedule is set up to refresh current events every 5 minutes.1.    Create an EventBridge event rule named "scheduled-refresh-currentEvents" and schedule it to run every 5 minutes using cron or rate expressions similar to the following:aws events put-rule \--name scheduled-refresh-currentEvents \--schedule-expression "cron(0/5 * * * ? *)"2.    Create and save a JSON file named refreshCurrentEvents.json using your favorite text editor that contains the cluster, role, and the AWS Secrets Manager ARN:{  "Rule": "scheduled-refresh-currentEvents",  "EventBusName": "default",  "Targets": [    {      "Id": "scheduled-refresh-currentEvents",      "Arn": "<Clsuter ARN>",      "RoleArn": "<Role ARN>",      "RedshiftDataParameters": {        "SecretManagerArn": "<Secrets Manager ARN>",        "Database": "<Database Name>",        "Sql": "REFRESH MATERIALIZED VIEW currentEvents;",        "StatementName": "scheduled-refresh-currentEvents",        "WithEvent": true      }    }  ]}3.    Create an event target using the saved JSON file:aws events put-targets --cli-input-json file://refreshCurrentEvents.json4.    To remove the target and delete the rule, run the following commands:aws events remove-targets --rule scheduled-refresh-currentEvents --ids scheduled-refresh-currentEventsaws events delete-rule --name scheduled-refresh-currentEventsView SQL status and resultsTo view the query status and result, follow these steps:1.    Open the Amazon RedShift console.2.    In the navigation pane, choose Query editor, and then choose Scheduled queries.3.    Choose your query name.4.    In Schedule history, note the ID. You will need the ID in step 7.5.    To retrieve the query results, assume the IAM role used to schedule the query using the AWS CLI command assume-role similar to the following:aws sts assume-role --role-arn "<Role ARN>" --role-session-name AWSCLI-SessionThe output returns the access key ID, secret access key, and session token.6.    Configure environment variables using the following export commands:export AWS_ACCESS_KEY_ID=<RoleAccessKeyID>export AWS_SECRET_ACCESS_KEY=<RoleSecretKey>export AWS_SESSION_TOKEN=<RoleSessionToken>7.    Retrieve the results using the AWS CLI command redshift-data similar to the following:aws redshift-data get-statement-result --id <ID> --region <Region>Related informationWhy can't I connect to the Amazon Redshift query editor?Using the Amazon Redshift Data API to interact with Amazon Redshift clustersCreating an Amazon EventBridge rule that runs on a scheduleFollow"


Question: How do I resolve access denied errors using Redshift Spectrum with Amazon S3 buckets in the same account as Amazon Redshift?

"I want to access data stored in Amazon Simple Storage Service (Amazon S3) buckets within the same account as my Amazon Redshift cluster. I also want to access the data using Amazon Redshift Spectrum with AWS Glue as my data catalog. But, I receive permission errors."

Answer: "I want to access data stored in Amazon Simple Storage Service (Amazon S3) buckets within the same account as my Amazon Redshift cluster. I also want to access the data using Amazon Redshift Spectrum with AWS Glue as my data catalog. But, I receive permission errors.Short descriptionThe AWS Identity and Access Management (IAM) role that's attached to the Redshift cluster, must have permissions on the AWS Glue and S3 services. If the IAM role doesn't have the correct permissions, then you might receive any of the following errors:When creating an external schema:SQL Error [XX000]: ERROR:   User: arn:aws:sts::111111111111:assumed-role/KCARole/RedshiftIamRoleSession is not authorized to perform: glue:CreateDatabase on resource: arn:aws:glue:eu-west-1:111111111111:catalog because no identity-based policy allows the glue:CreateDatabase actionWhen trying to query a Redshift Spectrum table:SQL Error [XX000]: ERROR: Spectrum Scan Error  Detail:   -----------------------------------------------  error:  Spectrum Scan Error  code:      15007  context:   Forbidden: HTTP response error code: 403 Message: AccessDenied Access DeniedWhen trying to query a Redshift Spectrum table and the S3 bucket is using a Key Management Services (AWS KMS) encryption key:SQL Error [XX000]: ERROR: Spectrum Scan Error  Detail:   -----------------------------------------------  error:  Spectrum Scan Error  code:      15007  context:   Forbidden: HTTP response error code: 403 Message: AccessDenied The ciphertext refers to a customer master key that does not exist, does not exist in this region, or you are not allowed to accessTo resolve these errors, you must attach an IAM policy with the required permissions to the IAM role used by Amazon Redshift. If the S3 bucket is encrypted using a KMS key, you must also attach permissions to use the key.ResolutionAttach the AWS managed policy AWSGlueConsoleFullAccess to the IAM role that's attached to the Redshift cluster.Create an IAM policy using the following example and attach the policy to the IAM role that's attached to the Redshift cluster. This allows read access to the S3 bucket where the data is stored:Note: Replace bucket name with the name of your S3 bucket.{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "Allows Redshift to Read S3 bucket specified",      "Effect": "Allow",      "Action": [        "s3:GetObject",        "s3:ListBucket"      ],      "Resource": [        "arn:aws:s3:::<bucket name>/*",        "arn:aws:s3:::<bucket name>"      ]    }  ]}If the S3 bucket that Redshift Spectrum is using is encrypted using an AWS KMS encryption key, then create and attach the following IAM policy. Attach the policy to the IAM role that's attached to the Redshift cluster. This policy provides access so that Redshift Spectrum can decrypt the encrypted data in Amazon S3. The following is an example of the minimum permissions to allow decryption:Note: Replace region with the AWS Region your S3 bucket is located in, replace AWS account ID with your account ID, and replace KMS key ID with the KMS encryption key.{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "Allow Redshift to use the KMS key",      "Effect": "Allow",      "Action": [        "kms:Decrypt",        "kms:GenerateDataKey"      ],      "Resource": [        "arn:aws:kms:<region>:<AWS account ID>:key/<KMS key ID>"      ]    }  ]}Related informationHow can I create Amazon Redshift Spectrum cross-account access to AWS Glue and Amazon S3?IAM policies for Amazon Redshift SpectrumFollow"


Question: How can I set up Active-Passive failover with geolocation records in Route 53?

I want to set up Active-Passive failover with geolocation records in Amazon Route 53.

Answer: "I want to set up Active-Passive failover with geolocation records in Amazon Route 53.Short descriptionIf a geolocation record is unhealthy, then Route 53 looks for another record for the larger, associated geographic AWS Region. If the client's location doesn't match the other healthy geolocation record, then Route 53 fails over to the default geolocation record.You can configure Route 53 to fail over to the other healthy geolocation record instead of the default geolocation record.ResolutionThis resolution uses the following example scenario:You have a geolocation record that points to a load balancer in one location. You create a secondary geolocation record for the same location. With this configuration, if the primary record becomes unhealthy, Amazon Route 53 automatically fails over to the secondary record. You have the following:A geolocation record for clients in Location A to access a load balancer in us-west-1.A geolocation record for clients in Location B to access the load balancer in eu-west-1.A default geolocation record that points to a static webpage showing that the service is unavailable to clients outside of Location A and Location B.For DNS queries from Location A:Create a primary failover record that points to the load balancer in us-west-1Create a secondary failover record that points to the load balancer in eu-west-1Create a geolocation record for Location A that points to the failover recordUsing the preceding configuration, if Route 53 receives a DNS query from Location A, then Route 53 responds with the primary failover record. If the load balancer is healthy, then the primary failover record is the load balancer in us-west-1. If the load balancer in us-west-1 is unhealthy, then Route 53 returns the load balancer in eu-west-1 (the secondary record).Step 1: Create two failover records for Location AOpen the Route 53 console.In the navigation pane, choose Hosted zones.Choose the name of the hosted zone that you want to create the records in.Choose Create record. You can use the wizard to create the records or choose Switch to quick create.Specify the following values:For Routing policy, choose FailoverFor Record name, enter a name for the failover recordFor supported AWS resources, you can create an alias record. If you're using Quick create, turn on Alias by using the toggle button. If you're using the Wizard, you don't have to turn on Alias and can proceed to Define failover record.Note: If the resource isn't supported for an alias record, create the record as a non-alias record. For more information, see Record type.For Value, choose the Endpoint (for example Alias to Application and Classic Load Balancer). Choose the Region (us-west-1, in this example), Then choose your target resource (load balancer, in this example).For Failover record type, choose PrimaryFor Evaluate target health, choose Yes.Note: The Evaluate target health option is applicable for alias records. If you're creating a non-alias record, create a Route 53 Health Check and associate it with the record.For Record ID, enter a value that uniquely identifies each record that has the same name and type.When using the Quick create record creation method, choose Add another record to create the secondary failover record. When using the Wizard, choose Define failover record.The Record name in this step is the same name that is specified for the primary record.For Value, choose the endpoint (for example, Alias to Application and Classic Load Balancer). Choose the Region (eu-west-1, in this example). Then, choose your target resource (load balancer, in this example).For Routing Policy, choose Failover.For Failover record type, choose Secondary.(Optional) For Evaluate target health, choose Yes if you're creating an alias record.For Record ID, enter a value that uniquely identifies each record that has the same name and type.Choose Create records.Step 2: Create a geolocation record targeting the failover recordOpen the Route 53 console.Choose Hosted zones.Choose the name of the required hosted zone that you want to create the record in.Choose Create Record. You can use the wizard to create the records or choose Switch to quick create.Specify the following values:For Routing policy, choose Geolocation.For Record name, specify a name for the geolocation record.For Record type, choose the same type that you used for the failover record.For supported AWS resources, you can create an alias record. If you're using Quick create, turn on Alias by using toggle button. If you're using the Wizard, you don't have to perform this action and can proceed to choose Define failover record.Note: If the resource isn't supported for an alias record, create the record as a non-alias record. For more information, see Record type.For Value, choose Alias to another record in this hosted zone, and then choose the failover recordFor Location, choose Location A's location.For Evaluate target health, choose Yes.For Record ID, enter a value that uniquely identifies each record that has the same name and type.Choose Create records.To complete the Active-Passive failover configuration between the two locations, repeat the steps above for clients in Location B.For DNS queries from Location B, do the following:Create a primary failover record that points to the load balancer in eu-west-1.Create a secondary failover record that points to the load balancer in us-west-1.Create a geolocation record for Location B that points to the failover record. Make sure that both geolocation records for location A and B are in the same hosted zone.Note: Use the same DNS record type for all of the records. For example, if you create an A record for the primary failover record:The secondary failover record must also be an A record.The geolocation record must be a type A Alias record.Related informationValues specific for geolocation alias recordsFollow"


Question: How do I launch Microsoft SQL Server on an EC2 Windows instance?

I want to launch Microsoft SQL Server on my Amazon Elastic Compute Cloud (Amazon EC2) Windows instance. How can I do this?

Answer: "I want to launch Microsoft SQL Server on my Amazon Elastic Compute Cloud (Amazon EC2) Windows instance. How can I do this?Short descriptionNew SQL environment deployments are classified under three categories:SQL Server standaloneSQL Server failover cluster instances (FCI)SQL Server Always On availability groups (AG)Before launching SQL Server on your instance, review the following points:The built-in availability form of clustering in Windows Server is activated by a feature named Failover Clustering. This feature allows you to build a Windows Server Failover Cluster (WSFC) to use with an AG or FCI.Always On is an umbrella term for the availability features in SQL Server and the term covers both availability groups and FCIs. Always On isn't the name of the AG feature.The major difference between FCI and AG is that all FCIs require some sort of shared storage, even if it's provided through networking. The FCI's resources can be run and owned by one node at any given time. An AG doesn't require that shared storage is also highly available. It's recommended to have replicas that are local in one data center for high availability and remote in other data centers for disaster recovery. Each replica with separate storage.An AG also has another component called the listener. The listener allows applications and end users to connect without needing to know which SQL Server instance is hosting the primary replica. Each AG has its own listener.For a list of supported versions and minimum requirements, see Using SQL Server in Windows on the Microsoft website.You can use AWS Launch Wizard to launch Microsoft SQL Server on Amazon EC2. AWS Launch Wizard supports all SQL Server deployment options. For more information, see What is AWS Launch Wizard for SQL Server?ResolutionDeploy SQL Server standaloneTo use the AWS Launch Wizard, access the Launch Wizard console. For Deployment Model, choose SQL Server Single instance deployment to deploy your SQL Server database on a single node. For more information, see Deploy an application with AWS Launch Wizard for SQL Server on Windows.For SQL Server standalone deployment, you can use one of the Amazon Machine images (AMI) provided by AWS with an included SQL license. You must use the version of SQL that comes with the AMI. However, you can customize it for your needs using the setup included in the AMI. For more information, see SQL Server AMIs provided by AWS.Deploy SQL Server FCIFCIs provide availability for the entire installation of SQL Server, known as an instance. This means that everything inside the instance, including databases, SQL Server Agent jobs, and linked servers move to another server if the underlying server fails.To provide a shared storage for FCI use one of the following solutions:Use Amazon FSx for NetApp ONTAP. Deploy Amazon FSx for ONTAP, configure iSCSI Storage connections, and setup Window Failover Clustering (WSFC). For more information, see SQL Server high availability deployments using Amazon FSx for NetApp ONTAP.Use Amazon FSx share. Deploy Amazon FSx file systems in the same Availability Zones (AZ) as the SQL Server FCI cluster nodes. Additionally, deploy the file share witness into a third AZ to keep the majority vote if there is a loss of one AZ. For more information, see Simplify your Microsoft SQL Server high availability deployments using Amazon FSx for Windows File Server.To deploy SQL Server FCI, do the following:Before you begin, deploy Amazon FSx for NetApp ONTAP or Amazon FSx share using the instructions provided in the preceding section.After deploying a two-node cluster, deploy SQL Server onto it using the following steps:Connect to the first virtual machine by using the remote desktop protocol (RDP).In Failover Cluster Manager, make sure that all core cluster resources are on the first virtual machine. If necessary, move all resources to that virtual machine.Locate the installation media. If the virtual machine uses an AMI, then the media is located at C:\SQLServerSetup\Setup media.Select Setup. In the SQL Server Installation Center, select Installation.Select New SQL Server failover cluster installation. Follow the instructions in the wizard to install the SQL Server FCI.Note: The FCI data directories need to be on clustered storage. For Amazon FSx NetApp ONTAP, you can connect to the file system over iSCSI.After you complete the instructions in the wizard, setup installs a SQL Server FCI on the first node. Connect to the second node using RDP.Open the SQL Server Installation Center, and then select Installation.Select Add node to a SQL Server failover cluster. Follow the instructions in the wizard to install SQL Server and add the server to the FCI.To use the AWS Launch Wizard instead of manual deployment, access the  Launch Wizard console. For Deployment Model, choose High Availability deployment - Always On Failover Cluster Instances. For more information, see Simplify SQL Server Always On deployments with AWS Launch Wizard and Amazon FSx.Deploy SQL Server Always On availability group (AG)To use the AWS Launch Wizard, access Launch Wizard console. For Deployment Model, choose High Availability deployment - Always On availability. For more information, see Deploy an application with AWS Launch Wizard for SQL Server on Windows.To deploy manually, see How do I create a SQL Server Always On availability group cluster in the AWS Cloud?Connect to SQL ServerAfter deploying SQL Server on your instance, you can connect to it using one of the following tools:Use SQL Server Management Studio (SSMS). For more information, see How do I allow a domain user to access the SQL Server instance on an EC2 instance?Use SQL Server Configuration Manager. For more information, see SQL Server Configuration Manager on the Microsoft website.Related informationHow do I troubleshoot Microsoft SQL issues on my EC2 Windows instance?How do I upgrade my Microsoft SQL cluster on my EC2 Windows instance?Best practices for deploying Microsoft SQL Server on Amazon EC2AWS Launch Wizard for SQL ServerFollow"


Question: How do I set up cross-account streaming from Kinesis Data Firehose to Amazon OpenSearch Service?

I want to set up an Amazon Kinesis Data Firehose stream that sends data to an Amazon OpenSearch Service cluster in another account. How do I stream my data resources across different accounts?

Answer: "I want to set up an Amazon Kinesis Data Firehose stream that sends data to an Amazon OpenSearch Service cluster in another account. How do I stream my data resources across different accounts?Short descriptionYou can set up Kinesis Data Firehose and its dependencies, such as Amazon Simple Storage Service (Amazon S3) and Amazon CloudWatch, to stream across different accounts. Streaming data delivery works for publicly accessible OpenSearch Service clusters whether or not fine-grained access control (FGAC) is enabled. This article covers both use cases.To set up a Kinesis Data Firehose stream so that it sends data to an OpenSearch Service cluster, perform the following steps:1.    Create an Amazon S3 bucket in Account A.2.    Create a CloudWatch log group and log stream in Account A.3.    Create a Kinesis Data Firehose role and policy in Account A.4.    Create a publicly accessible OpenSearch Service cluster in Account B that the Kinesis Data Firehose role in Account A will stream data to.5.    (Optional) If fine-grained access control (FGAC) is enabled, log in to OpenSearch Dashboards and add a role mapping.6.    Update the AWS Identity Access Management (IAM) role policy for your Kinesis Data Firehose role in Account A to send data to Account B.7.    Create the Kinesis Data Firehose stream in Account A.8.    Test cross-account streaming to the OpenSearch Service cluster.ResolutionCreate an Amazon S3 bucket in Account ACreate an S3 bucket in Account A. The Amazon S3 bucket generates an Amazon Resource Name (ARN).Note: The complete ARN is used later to grant Kinesis Data Firehose access to save and retrieve records from the Amazon S3 bucket.Create a CloudWatch Log Group and Log Stream in Account ATo create a CloudWatch Log Group, perform the following steps:1.    Open the CloudWatch console.2.    In the navigation pane, choose Log groups.3.    Choose Create log group.4.    Enter a Log Group name.5.    Choose the Create log group button to save your new log group.6.    Search for your newly created log group, and then select it. The completion of this task verifies that you can now create a log stream.To create an Amazon CloudWatch log stream, perform the following steps:1.    Choose Create Log Stream.2.    Enter a Log Stream Name.3.    Choose Create Log Stream. This action saves your newly created log stream.Important: The CloudWatch log group and CloudWatch log stream names are required when creating Kinesis Data Firehose role policies.Create a Kinesis Data Firehose role and a policy in Account A1.    Navigate to the AWS Identity and Access Management (IAM) console.2.    Create an IAM policy that allows Kinesis Data Firehose to do the following: Saves stream logs to CloudWatch Records to Amazon S3 Streams data to the OpenSearch Service clusterFor example:{    "Version": "2012-10-17",    "Statement": [        {                      "Effect": "Allow",                "Action": [                "s3:AbortMultipartUpload",                "s3:GetBucketLocation",                "s3:GetObject",                "s3:ListBucket",                "s3:ListBucketMultipartUploads",                "s3:PutObject",                "s3:PutObjectAcl"            ],    "Resource": [                "<Bucket ARN>",                "<Bucket ARN>/*"                ]        },        {                "Effect": "Allow",                "Action": [                "logs:PutLogEvents"            ],                           "Resource": [                "arn:aws:logs:<region>:<account-id>:log-group:/aws/kinesisfirehose/<Firehose Name>:log-stream:*"                       ]        }    ]}Note: You'll append permissions to stream to the OpenSearch Service cluster policy later on. However, you must first create the cluster in Account B.3.    Save the policy.4.    Choose Create a role.5.    Add the newly created policy to your Kinesis Data Firehose role.Create a publicly accessible OpenSearch Service cluster in Account B to which the Kinesis Data Firehose role in Account A will stream data1.    Create your publicly accessible OpenSearch Service cluster in Account B.2.    Record the OpenSearch Service domain ARN. You'll need the ARN for a later step.3.    Configure your security settings for your cluster.Important: You must configure your OpenSearch Service security settings to allow the Kinesis Data Firehose role in Account A to stream to your OpenSearch Service cluster.To configure your security settings, perform the following steps:1.    In OpenSearch Service, navigate to Access policy.2.    Select the JSON defined access policy. Your policy must have the following permissions:{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Principal": {        "AWS": "*"      },      "Action": "es:*",      "Resource": "<ES Domain ARN in Account B>/*",      "Condition": {        "IpAddress": {          "aws:SourceIp": "<Your IP Address for OpenSearch Dashboards access>"        }      }    },    {      "Effect": "Allow",      "Principal": {        "AWS": "<Firehose Role ARN in Account A>"      },      "Action": [        "es:ESHttpPost",        "es:ESHttpPut"      ],      "Resource": [        "<ES Domain ARN in Account B>",        "<ES Domain ARN in Account B>/*"      ]    },    {          "Effect": "Allow",      "Principal": {        "AWS": "<Firehose Role ARN in Account A>"      },      "Action": "es:ESHttpGet",      "Resource": [        "<ES Domain ARN in Account B>/_all/_settings",        "<ES Domain ARN in Account B>/_cluster/stats",        "<ES Domain ARN in Account B>/index-name*/_mapping/type-name",        "<ES Domain ARN in Account B>/roletest*/_mapping/roletest",        "<ES Domain ARN in Account B>/_nodes",        "<ES Domain ARN in Account B>/_nodes/stats",        "<ES Domain ARN in Account B>/_nodes/*/stats",        "<ES Domain ARN in Account B>/_stats",        "<ES Domain ARN in Account B>/index-name*/_stats",        "<ES Domain ARN in Account B>/roletest*/_stats"      ]    }  ]}For more information about permissions within the OpenSearch Service policy, see Cross-account delivery to an OpenSearch Service destination.3.    (Optional) If fine-grained access control (FGAC) is enabled on your cluster, then log in to OpenSearch Dashboards and add a role mapping. The roll mapping allows the Kinesis Data Firehose role to send requests to OpenSearch Service.(Optional) If fine-grained access control (FGAC) is enabled, then log in to OpenSearch Dashboards and add a role mappingIf the OpenSearch Service cluster has fine-grained access control enabled, then you must login to OpenSearch Dashboards and add a role mapping to the Kinesis Data Firehose role. The role mapping provides the Kinesis Data Firehose role access to stream to the OpenSearch Service cluster.To log in to OpenSearch Dashboards and add a role mapping, perform the following steps:1.    Open Dashboards.2.    Choose the Security tab.3.    Choose Roles.4.    Choose the all_access role.5.    Choose the Mapped users tab.6.    Choose Manage mapping.7.    In the Backend roles section, enter the Kinesis Data Firehose role.8.    Choose Map.Update the IAM role policy for your Kinesis Data Firehose role in Account A to send data to Account BTo send data from your Kinesis Data Firehose role in Account A to your OpenSearch Service cluster in Account B, update the Kinesis Data Firehose policy like this:{    "Version": "2012-10-17",    "Statement": [        {                      "Effect": "Allow",                "Action": [                "s3:AbortMultipartUpload",                "s3:GetBucketLocation",                "s3:GetObject",                "s3:ListBucket",                "s3:ListBucketMultipartUploads",                "s3:PutObject",                "s3:PutObjectAcl"            ],            "Resource": [                "<Bucket ARN>",                "<Bucket ARN>/*"                ]        },        {                "Effect": "Allow",                "Action": [                "logs:PutLogEvents"            ],                           "Resource": [                "arn:aws:logs:<region>:<account-id>:log-group:/aws/kinesisfirehose/<Firehose Name>:log-stream:*"            ]        },             {            "Effect": "Allow",            "Action": [                "es:ESHttpPost",                "es:ESHttpPut",                "es:DescribeDomain",                    "es:DescribeDomains",                "es:DescribeDomainConfig"            ],            "Resource": [                "<Domain ARN in Account B>",                "<Domain ARN in Account B>/*"            ]        },        {                    "Effect": "Allow",            "Action": [                "es:ESHttpGet"            ],            "Resource": [                "<Domain ARN in Account B>/_all/_settings",                "<Domain ARN in Account B>/_cluster/stats",                "<Domain ARN in Account B>/index-name*/_mapping/superstore",                "<Domain ARN in Account B>/_nodes",                "<Domain ARN in Account B>/_nodes/stats",                "<Domain ARN in Account B>/_nodes/*/stats",                "<Domain ARN in Account B>/_stats",                "<Domain ARN in Account B>/index-name*/_stats"            ]        }    ]}For more information about sending Kinesis Data Firehose data to your OpenSearch Service cluster, see Grant Kinesis Data Firehose access to an Amazon OpenSearch Service destination.Create the Kinesis Data Firehose stream in Account ATo create a Kinesis Data Firehose stream with cross-account access to an OpenSearch Service cluster, use and configure the AWS Command Line Interface (AWS CLI).Check to make sure that your AWS CLI is up-to-date:aws --versionNote: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent AWS CLI version.After the AWS CLI is updated, create a file called input.json with the following content:{    "DeliveryStreamName": "<Firehose Name>",    "DeliveryStreamType": "DirectPut",    "ElasticsearchDestinationConfiguration": {        "RoleARN": "",        "ClusterEndpoint": "",        "IndexName": "local",        "TypeName": "TypeName",        "IndexRotationPeriod": "OneDay",        "BufferingHints": {            "IntervalInSeconds": 60,            "SizeInMBs": 50        },        "RetryOptions": {            "DurationInSeconds": 60        },        "S3BackupMode": "FailedDocumentsOnly",        "S3Configuration": {            "RoleARN": "",            "BucketARN": "",            "Prefix": "",            "BufferingHints": {                "SizeInMBs": 128,                "IntervalInSeconds": 128            },            "CompressionFormat": "UNCOMPRESSED",            "CloudWatchLoggingOptions": {                "Enabled": true,                "LogGroupName": "/aws/kinesisfirehose/<Firehose Name>",                "LogStreamName": "S3Delivery"            }        },        "CloudWatchLoggingOptions": {            "Enabled": true,            "LogGroupName": "/aws/kinesisfirehose/<Firehose Name>",            "LogStreamName": "ElasticsearchDelivery"        }    }}Make sure that the endpoint value is correctly entered in the ClusterEndpoint attribute field.Note: Types are deprecated in Elasticsearch version 7.x. For Elasticsearch versions 7.x, make sure to remove the TypeName attribute from the input.json file.Then, run the following CLI command in the same directory as the location of the input.json file:aws firehose create-delivery-stream --cli-input-json file://input.jsonThis command syntax creates a Kinesis Data Firehose stream in Account A with a destination to an OpenSearch Service cluster in Account B.Test cross-account streaming to the OpenSearch Service clusterUse the Kinesis Data Generator to stream records into the Kinesis Data Firehose stream in Account A.The Kinesis Data Generator (KDG) generates many records per second. This productivity level allows OpenSearch Service to have enough data points to determine the correct mapping of a record structure.Here is the template structure used in the Kinesis Data Generator:{    "device_id": {{random.number(5)}},    "device_owner": "{{name.firstName}}  {{name.lastName}}",    "temperature": {{random.number(        {            "min":10,            "max":150        }    )}},    "timestamp": "{{date.now("DD/MMM/YYYY:HH:mm:ss Z")}}"}To verify whether cross-account streaming was successful, review the index entries under the Indices tab of your cluster. Check whether there is an index name using the prefix "local" with the current date. You can also check if the records are present in OpenSearch Dashboards.Note: OpenSearch Service takes a few minutes to determine the correct mapping.Related informationCreating an Amazon Kinesis Data Firehose delivery streamWriting to Kinesis Data Firehose using Kinesis Data StreamsFollow"


Question: How do I use CloudTrail LookupEvents to find the source of "Rate exceeded" errors associated with Lambda function management event API calls?

I want to use Amazon CloudTrail LookupEvents to find the source of errors caused by exceeding AWS Lambda function quotas limits.

Answer: "I want to use Amazon CloudTrail LookupEvents to find the source of errors caused by exceeding AWS Lambda function quotas limits.ResolutionYou might receive a "Rate exceeded" error when your environment exceeds Lambda function quota limits for API requests. Before you resolve a "Rate exceeded" error, review your CloudTrail event logs.1.    Run the CloudTrail lookup-events AWS Command Line Interface (AWS CLI) command to view the total count of management event API calls.Note: Set the start-time, end-time, and time zone for each value to match the problematic timeframe.aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventSource,AttributeValue=lambda.amazonaws.com --start-time YYYY-MM-DDTHH:MM:SS+00:00 --end-time YYYY-MM-DDTHH:MM:SS+00:00 | grep -i EventName | grep -v CloudTrailEvent | sort | uniq -c | sort -rNote: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.Example CloudTrail lookup-events AWS CLI command:aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventSource,AttributeValue=lambda.amazonaws.com --start-time 2023-04-03T18:29:00+05:30 --end-time 2023-04-03T18:29:30+05:30 | grep -i EventName | grep -v CloudTrailEvent | sort | uniq -c | sort -rExample CloudTrail lookup-events AWS CLI command output:2072    "EventName": "ListVersionsByFunction20150331", 877    "EventName": "GetFunction20150331v2", 245    "EventName": "GetFunctionCodeSigningConfig", 210    "EventName": "UpdateFunctionCode20150331v2", 210    "EventName": "ListTags20170331", 206    "EventName": "GetRuntimeManagementConfig", 121    "EventName": "PublishVersion20150331", 106    "EventName": "UpdateAlias20150331", 89     "EventName": "GetPolicy20150331v2",  2     "EventName": "ListLayers20181031",2.    Run the CloudTrail lookup-events command to view the total count of API calls that each user made.Note: Set the start-time, end-time, and time zone for each value to match the problematic timeframe.aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventSource,AttributeValue=lambda.amazonaws.com --start-time YYYY-MM-DDTHH:MM:SS+00:00 --end-time YYYY-MM-DDTHH:MM:SS+00:00 | grep -i Username | grep -v CloudTrailEvent | sort | uniq -c |. sort -rExample CloudTrail lookup-events AWS CLI command:aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventSource,AttributeValue=lambda.amazonaws.com --start-time 2023-04-03T18:29:00+05:30 --end-time 2023-04-03T18:29:30+05:30 | grep -i Username | grep -v CloudTrailEvent | sort | uniq -c | sort -rExample CloudTrail lookup-events AWS CLI command output:4047   "Username": "AWSCloudFormation", 89    "Username": "auditor",  2    "Username": "appsync",3.    If necessary, run the CloudTrail lookup-events command again to identify users or events that might be making a high number of API calls.4.    After you review the output of the CloudTrail lookup-events command, review the source of the API calls that exceed the Lambda function quota limits.Related informationHow do I prevent "Rate exceeded" errors in CloudFormation?How do I troubleshoot Lambda function throttling with "Rate exceeded" and 429 "TooManyRequestsException" errors?Follow"


Question: How can I configure and use SAR to monitor performance metrics on my EC2 Linux instance?

I want to configure System Activity Reporter (SAR) and use SAR commands to monitor my Amazon Elastic Compute Cloud (Amazon EC2) Linux instances performance metrics. How can I do this?

Answer: "I want to configure System Activity Reporter (SAR) and use SAR commands to monitor my Amazon Elastic Compute Cloud (Amazon EC2) Linux instances performance metrics. How can I do this?Short descriptionThe SAR monitoring tool allows you to collect performance data as needed for CPU, memory, and I/O usage. You can configure SAR to collect historical metrics.ResolutionInstall SARSAR, which is part of the sysstat package, might not be available by default on newer Linux distributions. For detailed installation instructions, see How do I configure the ATOP and SAR monitoring tools for my EC2 instance running Amazon Linux, RHEL, CentOS, or Ubuntu?Configuration overviewYou can view and edit the configuration file,/etc/sysconfig/sysstat, after installation. The configuration file contains the following default values:HISTORY=28 - This parameter determines how long SAR keeps performance log files. The default value is 28 days.COMPRESSAFTER=31 - This parameter determines after how many days SAR compresses files. The default value is 31 days.Note: If you set the configuration file to keep log files longer than 28 days, then SAR keeps each month's files in a separate directory.SA_DIR=/var/log/sa - SAR saves log files to this location.ZIP="bzip2" - This is the default zip file containing compressed log files. Make sure that you enable compression if you keep files for more than 31 days. Compressed files occupy the least possible space on the disk.The sadc (system activity data collector) operation performs data collection. Collected data is written in text format and contained in the sar## files in the /var/log/sa/ directory.The sadc operation is classified into two components:sa1 - Collect and store binary data in the system activity daily data file.sa2 - Write a daily report to the /var/log/sa directory.The /var/log/sa/ directory contains the following two sets of files:sa# - system activity binary data files.sar## - system activity report files.Note: ## represents the day of the month.You can collect data other than disk statistics, such as partition and file system statistics*.* To change what data is collected, do the following:1.    Access the /etc/sysconfig/sysstat file using a text editor, such as the vi editor:vi /etc/sysconfig/sysstat2.    Change SADC_OPTIONS from -S Disk to -S XALL:SADC_OPTIONS=" -S XALL"Set data collection intervalsRun the following command to view the scripts that the SAR utility currently runs in crontab to generate data:cat /etc/cron.d/sysstatBy default, SAR generates data every 10 minutes. This is due to cron, which runs every 10 minutes. You can edit this time to allow SAR to generate data for shorter or longer intervals. The following is an example of the crontab file showing that the data is set to generate every 10 minutes:*/10 * * * * root /usr/lib64/sa/sa1 1 1It's a best practice to change cron to run on a 5 or 1 minute interval. By changing to a shorter interval, you can catch cases where spikes are observed or when every minute monitoring is required.To change the interval:1.    Access the /etc/cron.d/sysstat file:vim /etc/cron.d/sysstatChange the run time from 10 to 5:@reboot /usr/lib64/sa/sa1 --boot*/5 * * * * root /usr/lib64/sa/sa1 1 1Note: In the previous example, the @reboot line resets the counter when the OS reboots. This is optional, but is a best practice.Example commands to generate performance reports as neededCPU usage reportUse the sar command to generate a CPU usage data report. The following example command generates a usage data report 5 times every 2 seconds. In the following command, -P indicates an individual CPU or core. Indicate which CPU or core you want to generate statistics for using 0, 1, 2, 3, and so on. Or, you can use the command -P ALL to display statics for all CPUs.sar 2 5 -P 0Memory statistics reportUse the -r option to generate a memory statistics report. The following example command generates memory statistics 5 times every 2 seconds:sar -r 2 5Block device statistics reportUse the -d option to generate a block device statistics report. The following example command generates block device statistics 5 times every 2 seconds. In the following example, the -p option displays the device names as they appear in /dev:sar -d -p 2 5Network statistics reportUse the -n option to generate a network statistics report. You can generate statistics for specific entities, such as TCP, UDP, NFS, etc. or ALL as shown in the following examples:sar -n TCP 2 5sar -n UDP 2 5sar -n ALL 2 5Read the most recent log fileRunning sar commands extracts details from the most recent log file in /var/log. To read the complete file, use the -f option, as shown in the following example:sar -f /var/log/saExtract log details for a specific dayThe log file is saved by day. If you want to extract details for a specific day, use the -f option for the relevant sa file on that date. For example, the following command displays all the data from the log file containing data from the 12th day of the current month:sar -f /var/log/sa/sa12Read specific statistics from a log fileMemory statisticsUse the -r option to read all memory statistics. The following example command displays all memory statistics from the log file generated on the 12th day of the month:sar -f /var/log/sa/sa12 -rI/O activityUse the -b option to display all combined I/O activity. The following example command displays all I/O activity from the log file generated on the 12th day of the month.sar -f /var/log/sa/sa12 -bBlock device statisticsUse the -dp option to display block device statistics. The following example command displays block device statistics from the log file generated on the 12th day of the month.sar -f /var/log/sa/sa12 -dpNetwork statisticsUse the -n option to display network statistics. The following example command displays all network statistics from the log file generated on the 12th day of the month:sar -f /var/log/sa/sa12 -n ALLCPU statisticsUse the -P option to display CPU statistics. The following example command displays CPU statistics for CPU 0.sar -f /var/log/sa/sa12 -P 0View statistics for a specific time periodUse the -s and -e options to designate start and end times. The times entered must be in the 24 hour format. The default end time is 18:00. The following example command displays block device statistics from the log file generated on the 30th day of the month between 2:00 and 5:00.sar -f /var/log/sa/sa30 -dp -s 02:00:00 -e 05:00:00Related informationsar(1) -Linux man pageFollow"


Question: I received the message "NetworkInterfaces associated with the Lambda Function to be cleaned up" when deleting a CloudFormation stack.

"I tried to delete an AWS CloudFormation stack, and received the message "CloudFormation is waiting for NetworkInterfaces associated with the Lambda function to be cleaned up". How do I fix this issue?"

Answer: "I tried to delete an AWS CloudFormation stack, and received the message "CloudFormation is waiting for NetworkInterfaces associated with the Lambda function to be cleaned up". How do I fix this issue?Short descriptionRequester-managed network interfaces are network interfaces created in your Amazon Virtual Private Cloud (Amazon VPC) by AWS services such as AWS Lambda. AWS CloudFormation uses elastic network interfaces, and elastic network interfaces can only be deleted by Lambda. Deleting an elastic network interface can take up to 45 minutes. This length of time depends on factors such as how many Lambda functions are using the elastic network interface.ResolutionTo reduce the time to deleting elastic network interfaces with CloudFormation stacks, follow these steps.1.    Make sure that the elastic network interface isn't used by other Lambda functions or versions. If the elastic network interface is associated with a Lambda function version, you must delete the function versions. This is because published Lambda function versions can’t be edited, and the Amazon VPC configuration can’t be changed. Follow the instructions to run the Lambda elastic network interface finder and delete the network interface.2.    Route traffic away from the Lambda function before deleting the CloudFormation stack. This makes sure that the elastic network interface is removed automatically before the CloudFormation stack deletion. Manually change the Amazon VPC configuration for each Lambda function that share the same security group subnet combination to none. The Lambda service automatically deletes the elastic network interface after no traffic is routed.Note: Lambda doesn't delete network interfaces for AWS accounts that are used by functions or function versions with the same Amazon VPC configurations as the functions that created the network interfaces.Related informationHow do I delete an AWS Lambda-backed custom resource that's stuck in DELETE_FAILED status or DELETE_IN_PROGRESS status in CloudFormation?What are some best practices for implementing AWS Lambda-backed custom resources with AWS CloudFormation?Follow"


Question: How do I set up Kubernetes Metrics Server and Horizontal Pod Autoscaler on Amazon EKS?

I want to set up Kubernetes Metrics Server and Horizontal Pod Autoscaler (HPA) on Amazon Elastic Kubernetes Service (Amazon EKS).

Answer: "I want to set up Kubernetes Metrics Server and Horizontal Pod Autoscaler (HPA) on Amazon Elastic Kubernetes Service (Amazon EKS).ResolutionSet up your environment1.    Create an Amazon Elastic Compute Cloud (Amazon EC2) instance.2.    Install kubectl on your EC2 instance.3.    Install and configure the latest version of the AWS Command Line Interface (AWS CLI) on your EC2 instance.4.    Configure your kubeconfig file to point to the Amazon EKS cluster.Create a Kubernetes Metrics Server1.    To install Metrics Server, run the following command:kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml2.    To confirm that Metrics Server is running, run the following command:kubectl get pods -n kube-system -l k8s-app=metrics-serverThe output is similar to the following:kubectl get pods -n kube-system -l k8s-app=metrics-servermetrics-server-85cc795fbf-79d72   1/1     Running   0          22sCreate a php-apache deployment and a service1.    To create a php-apache deployment, run the following command:kubectl create deployment php-apache --image=k8s.gcr.io/hpa-example2.    To set the CPU requests, run the following command:kubectl patch deployment php-apache -p='{"spec":{"template":{"spec":{"containers":[{"name":"hpa-example","resources":{"requests":{"cpu":"200m"}}}]}}}}'Important: If you don't set the value for cpu correctly, then the CPU utilization metric for the pod isn't defined and the HPA can't scale.3.    To expose the deployment as a service, run the following command:kubectl create service clusterip php-apache --tcp=804.    To create an HPA, run the following command:kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=105.    To confirm that the HPA was created, run the following command:kubectl get hpa6.    To create a pod to connect to the deployment that you created earlier, run the following command:kubectl run -i --tty load-generator --image=busybox /bin/sh7.    To test a load on the pod in the namespace that you used in step 1, run the following script:while true; do wget -q -O- http://php-apache; doneNote: To exit the while loop and the tty session of the load generator pod, use CTRL + C to cancel the loop. Then, use CTRL + D to exit the session.8.    To see how the HPA scales the pod based on CPU utilization metrics, run the following command (preferably from another terminal window):kubectl get hpa -wThe Metrics Server is now up and running, and you can use it to get resource-based metrics.9.    To clean up the resources used for testing the HPA, run the following commands:kubectl delete hpa,service,deployment php-apachekubectl delete pod load-generatorRelated informationHorizontal Pod AutoscalingFollow"


Question: How do I pre-register a Sender ID for India in Amazon SNS?

I want to preregister a Sender ID for India in Amazon Simple Notification Service (Amazon SNS).

Answer: "I want to preregister a Sender ID for India in Amazon Simple Notification Service (Amazon SNS).ResolutionUnderstand the special requirements for sending SMS messages to recipients in India.Register with the Telecom Regulatory Authority of India (TRAI).Request a Sender ID.Send SMS messages.Note: To send SMS messages to Indian recipients using the Amazon SNS console, see step 9 in Sending a message (console).Related informationTroubleshooting SMS messages sent to recipients in IndiaFollow"


Question: How do I use AWS WAF with AWS Global Accelerator to protect my application from malicious attacks?

I want to protect my application from Layer 7 DDoS attacks by using the AWS WAF rate limiting rule with the Application Load Balancer behind the Global Accelerator.

Answer: "I want to protect my application from Layer 7 DDoS attacks by using the AWS WAF rate limiting rule with the Application Load Balancer behind the Global Accelerator.Short descriptionYou can leverage AWS Global Accelerator, Application Load Balancer, and AWS WAF to defend against application layer Distributed Denial of Service (DDoS) attacks.Note: Client rate limiting through the Application Load Balancer and WAF requires that you set source IP preserved=TRUE on the accelerator. For more information, see Preserve client IP addresses in AWS Global accelerator.ResolutionThe AWS WAF rate limiting rule lets you automatically block clients from specific IP addresses that send an overwhelming flood of requests to your application. Your rate-based rule tracks the number of requests sent out by each IP address, based on a sliding time window. When the requests exceed the rate limit, the rule immediately blocks requests from the source IP address, until the address lowers the number of requests. Note: You can also configure the rule to inspect and block many components of a request, including the country originating the request.PrerequisitesMake sure that you have the following traffic flow configuration for Global Accelerator, Application Load Balancer, and AWS WAF:User --> Global Accelerator --> Application Load Balancer with WAF --> EC2 instanceNote: In this setup, the user accesses the application by making a request to the accelerator. The accelerator routes user traffic to the Application Load Balancer and WAF associated with it. WAF evaluates and either blocks or allows the user request using the rate limiting rule that you create.Install a load testing tool, such as loadtest from GitHub. Or, use a load testing tool of your choice that gives you the required visibility.Create a rule-based web ACLCreate a rate-based rule in web ACL, with an aggressive rate limit of 100. Then, use the test case to check if your rule's working.Navigate to the AWS WAF Console to create a web ACL rule.Add a custom rule to your web ACL.Give it a name and set the rate-based rule as Type.Set 100 as its Rate limit.Leave all other settings as-is. Then, click Add Rule.Save web ACL.Test the resultsThe test simulates an HTTP flood attack. The load testing tool shows the progress of received requests. At some stage the requests start failing because they get blocked by the rate-limiting rule you set up.Run the loadtest tool on your computer.Note: Or, open AWS CloudShell on your console (you might receive a prompt to switch to the Region where it's supported).# Install globally as root:npm install -g loadtest# On AWS CloudShell, Ubuntu or Mac OS X systems install using sudo:sudo npm install -g loadtestEnter the Global Accelerator's URL, as shown below:# Global Accelerator urlGA_URL=http://your_Global_Acclerator_URLNote: Replace your_Global_Accelerator_URL with your Global Accelerator URL.Run the command in your terminal to start the load testing simulation flood of requests.Note: This should take 45 seconds to run, so keep an eye on the flow.loadtest -n 1000 -c 1 --rps 25 $GA_URLThe command sends a total of 1000 requests, with concurrency 1 and 25 requests per second. With this rate of requests per second you reach the limit you set by the fourth second.Analyze the output flow. Notice that at some stage the requests began to fail. The errors indicate that the WAF rule blocked all requests from your source IP address.[Fri Apr 21 2023 20:26:45 GMT+0000 ] INFO Requests: 0 (0%), requests per second: 0, mean latency: 0 ms[Fri Apr 21 2023 20:26:50 GMT+0000 ] INFO Requests: 106 (11%), requests per second: 21, mean latency: 22.9 ms[Fri Apr 21 2023 20:26:50 GMT+0000 ] INFO Errors: 106, accumulated errors: 106, 100% of total requestsFollow"


Question: How do I resolve a 554 "Access denied" error when I send an email from my IAM user in Amazon SES?

"When I send an email from my AWS Identity and Access Management (IAM) user in Amazon Simple Email Service (Amazon SES), I receive a 554 "Access denied" error."

Answer: "When I send an email from my AWS Identity and Access Management (IAM) user in Amazon Simple Email Service (Amazon SES), I receive a 554 "Access denied" error.Short descriptionYou send an email from your IAM user in Amazon SES, and you receive the following error:554 Access denied: User arn:aws:iam::123456789012:user/iam-user-name' is not authorized to perform ses:SendRawEmail' on resource `arn:aws:ses:eu-west-1:123456789012:identity/example.com'To troubleshoot the 554 "Access denied" error from Amazon SES, check the following:The user has the right policies and access to send emails.A sending authorization policy isn't attached to the email address or domain.The Resource element in the IAM policy is set to the email address identity's ARN.AWS Organizations service control policies (SCPs) aren't attached to the user.Resolution1.    Open the IAM console.2.    Under Policy summary, check the following:The IAM user has the right permission to send emails. For example, to permit the user to perform email-sending APIs, you must include the related actions (ses:SendEmail, ses:SendRawEmail, ses:SendTemplatedEmail, ses:SendBulkTemplatedEmail).The IAM user has the right access to send email from the identity. If you set the IAM user policy's Resource element to *, then the user has access to send email from all identities. If the Resource element is restricted, then check that the user has two policies, or two statements in a policy. The Action element of the first policy or statement must be set to one or more of the non-email-sending APIs. The Resource element must be set to *. The Action element of the second policy or statement must be set to one or more of the email-sending APIs. The Resource element must be set to the identity's ARN.The following is an example IAM policy with two statements. The policy permits the user to perform GetSendStatistics and GetSendQuota non-email-sending APIs, and restricts SendEmail and SendRawEmail email-sending APIs to send only from the domain.{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Action": [        "ses:GetSendStatistics",        "ses:GetSendQuota"      ],      "Resource": "*"    },    {      "Effect": "Allow",      "Action": [        "ses:SendEmail",        "ses:SendRawEmail"      ],      "Resource": "arn:aws:ses:eu-west-1:123456789012:identity/example.com"    }  ]}3.    Check if there's a sending authorization policy attached to the email address or domain that's preventing the user from sending emails.4.    If you verified the email address identity separately from the domain identity, then you must set the Resource element to the email address identity's ARN. For more information, see Creating and verifying identities in Amazon SES.5.    Check if there's an Organizations SCP policy that the user inherited. SCPs can prevent the user from sending emails. For example, the user inherited a Deny statement to use Amazon SES, or the user has access to only certain AWS or Amazon SES Regions.Note: Amazon SES Simple Mail Transfer Protocol (SMTP) credentials are unique to each AWS account, and specific to one Region.Related informationIdentity and access management in Amazon SESAmazon SES API referenceFollow"


Question: How do I access Amazon SNS topic delivery logs for SMS messages?

I want to access Amazon Simple Notification Service (Amazon SNS) topic delivery logs for SMS messages.

Answer: "I want to access Amazon Simple Notification Service (Amazon SNS) topic delivery logs for SMS messages.Short descriptionBefore you complete the following steps, confirm that you're using SNS endpoints with support for log delivery status of notification messages:HTTP(S)Amazon Kinesis Data FirehoseAWS LambdaPlatform application endpointAmazon Simple Queue Service (Amazon SQS)SMSNote: 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.ResolutionConfigure SMS delivery status attributes for Amazon CloudWatch LogsNote: As an alternative to the following console steps, you can configure message delivery status using AWS SDKs or the AWS CLI.1.    Open the Amazon SNS console.2.    On the navigation pane, expand Mobile, and then choose Text messaging (SMS).3.    In the Text messaging preferences section, choose Edit.4.    Expand Delivery status logging - optional.5.    For Success sample rate, in the % text box, enter 100.Note: Success rate is the percentage of successful message deliveries to the log.6.    In the IAM roles section, for Service role, select Create new service role, and then choose Create new roles. The AWS Identity and Access Management (IAM) console opens.Note: If you already have an IAM role with the right permissions, then you can use that service role by selecting Use existing service role instead.7.    On the IAM console permission request page, choose Allow.8.    After returning to the Amazon SNS console, choose Save changes.Now, an IAM role is created for successful and failed deliveries with the following policy and trust relationships for Amazon SNS.IAM role:arn:aws:iam::1111111111:role/SNSSuccessFeedbackPolicy:{    "Version": "2012-10-17",    "Statement": [        {            "Effect": "Allow",            "Action": [                "logs:CreateLogGroup",                "logs:CreateLogStream",                "logs:PutLogEvents",                "logs:PutMetricFilter",                "logs:PutRetentionPolicy"            ],            "Resource": [                "*"            ]        }    ]}Trust relationships:{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Principal": {        "Service": "sns.amazonaws.com"      },      "Action": "sts:AssumeRole"    }  ]}View delivery status logs1.    Open the Amazon CloudWatch console.2.    On the navigation pane, expand Logs, and then choose Log groups.3.    In the Filter search box, enter DirectPublishToPhoneNumber to find only SMS log groups for Amazon SNS.Note: Depending on the destination phone number's carrier, it can take up to 72 hours for delivery logs to appear in the Amazon SNS console.For example:The sns/your-AWS-region/your-AWS-account-ID/DirectPublishToPhoneNumber log group contains the successful delivery logs:sns/us-east-1/1111111111/DirectPublishToPhoneNumberSample successful delivery logs:{    "notification": {        "messageId": "34d9b400-c6dd-5444-820d-fbeb0f1f54cf",        "timestamp": "2016-06-28 00:40:34.558"    },    "delivery": {        "phoneCarrier": "My Phone Carrier",        "mnc": 270,        "destination": "+1XXX5550100",        "priceInUSD": 0.00645,        "smsType": "Transactional",        "mcc": 310,        "providerResponse": "Message has been accepted by phone carrier",        "dwellTimeMs": 599,        "dwellTimeMsUntilDeviceAck": 1344    },    "status": "SUCCESS"}The sns/your-AWS-region/your-AWS-account-ID/DirectPublishToPhoneNumber/Failure log group contains the failure delivery logs:sns/us-east-1/1111111111/DirectPublishToPhoneNumber/FailureSample failure delivery logs:{    "notification": {        "messageId": "1077257a-92f3-5ca3-bc97-6a915b310625",        "timestamp": "2016-06-28 00:40:34.559"    },    "delivery": {        "mnc": 0,        "destination": "+1XXX5550100",        "priceInUSD": 0.00645,        "smsType": "Transactional",        "mcc": 0,        "providerResponse": "Unknown error attempting to reach phone",        "dwellTimeMs": 1420,        "dwellTimeMsUntilDeviceAck": 1692    },    "status": "FAILURE"}4.    Choose the SNS log group that you want to view.5.    On the Log streams tab, choose a particular log stream to view the SMS delivery logs.6.    To see the delivery status of your SMS message, expand the log event and check providerResponse.View opted-out phone numbersRecipients can opt out of receiving SMS messages on their phones from their AWS account. For more information, see Opting out of receiving SMS messages.1.    Open the Amazon SNS console.2.    On the navigation pane, expand the Mobile section, and then choose Text Messaging (SMS).3.    To view opted-out phone numbers, go to the Opted-out phone numbers section.Related informationMonitoring Amazon SNS topics using CloudWatchSetting SMS messaging preferencesViewing Amazon CloudWatch metrics and logs for SMS deliveriesFollow"


Question: How can I configure TXT records that are longer than 255 characters in Route 53?

I want to configure text (TXT) records that are longer than 255 characters in Amazon Route 53.

Answer: "I want to configure text (TXT) records that are longer than 255 characters in Amazon Route 53.ResolutionNote: It's a best practice to create a TXT record that contains the applicable values instead of an SPF record. The Internet Engineering Task Force (IETF) in 2014 deprecated the SPF record type. Most email providers don't support SPF records. While Route 53 provides an option to create an SPF record, your email provider might not be able to identify the SPF record. Or, you might see the error SPF validation isn't working. For more information, see RFC 7208 on the IETF website.Creating TXT recordsKey points to remember:A TXT record contains one or more strings that are enclosed in double quotation marks (").You can enter a value of up to 255 characters in one string in a TXT record.You can add multiple strings of 255 characters in a single TXT record.The maximum length of a value in a TXT record is 4,000 characters.TXT record values are case-sensitive.For values that exceed 255 characters, break the value into strings of 255 characters or less. Enclose each string in double quotation marks (") using the following syntax: Domain name TXT "String 1" "String 2" "String 3"….."String N".For information on the values to specify in your TXT record, see Entering TXT record values.To create a TXT record to replace an SPF record:Open the Route 53 console.Choose Hosted zones.Select the domain of the SPF recordCopy the value of the SPF record, and then choose Create record.For Routing policy, choose Simple routing.Choose Next.Choose Define simple record.For Record name, specify a name.For Value/Route traffic to, choose IP address or another value depending on the record type. Then, paste the SPF record value that you copied in step 4.For Record type, choose TXT.For TTL (seconds), specify a time to live value.Choose Define simple record.The following example shows a TXT record that has configured values for domain verification, the SPF record, and DKIM signing:txt1.geeksbox.club. TXT 3600 "google-site-verification=rXOxyZounnZasA8Z7oaD3c14JdjS9aKSWvsR1EbUSIQ""v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all""spf2.0/pra include:spf1.amazon.com include:spf2.amazon.com include:amazonses.com -all""v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeIhtCv3vUinyhKiKtZ8efjHGGo8gE1T+o7gLrvo6yRtdz9ICe6Fz5sgz0WYFW5nCV4DmaTcS25TfgWKsLgg"Follow"


Question: Why can't I see my VPC endpoint service in the verified services list when I'm creating an interface VPC endpoint?

"I’m using Amazon Virtual Private Cloud (Amazon VPC) to create an interface VPC endpoint. However, I can't find the VPC endpoint service in the verified services section of the VPC endpoint services console from other accounts. How can I resolve this?"

Answer: "I’m using Amazon Virtual Private Cloud (Amazon VPC) to create an interface VPC endpoint. However, I can't find the VPC endpoint service in the verified services section of the VPC endpoint services console from other accounts. How can I resolve this?Short descriptionService consumers can connect to your AWS PrivateLink-powered services (VPC endpoint services) from another VPC using an interface VPC endpoint. Service consumers are Identity and Access Management principals. Service consumers can be IAM users, IAM roles, or AWS accounts.If you can't find the endpoint service when creating the interface VPC endpoint, make sure that the service endpoint provider account lists the service consumer account or user ARN under Allowed principals.ARNs appear in the following formats:An AWS account (and all principals in the account): arn:aws:iam::aws-account-id:root.A specific IAM user: arn:aws:iam::aws-account-id:user/user-name.A specific IAM role: arn:aws:iam::aws-account-id:role/role-name.ResolutionOpen Endpoint services in the VPC console.Choose the endpoint service.Select Actions, Allow principals.Verify that you can see the service consumer's ARN in Allowed principals. If the service consumer's ARN isn't listed, then select Allow principal.Enter the ARN of the service consumer account as arn:aws:iam::consumer_account_number:root in the ARN field, and then select Allow principals.For more information, see Add or remove permissions for your endpoint service.Related informationEndpoint service Availability Zone considerationsWhy can't I connect to an endpoint service from my interface endpoint in an Amazon VPC?Follow"


Question: How do I add the testng.xml file to the root of the *-tests.jar file in my Appium Java TestNG test package for AWS Device Farm?

"I want to configure Appium Java TestNG tests for my AWS Device Farm project. However, I need to add a testng.xml file into the root of the *-tests.jar file in my Appium test package first. How do I do that?"

Answer: "I want to configure Appium Java TestNG tests for my AWS Device Farm project. However, I need to add a testng.xml file into the root of the *-tests.jar file in my Appium test package first. How do I do that?Short descriptionConfigure the Apache Maven pom.xml file to package your testng.xml file into the root of your Appium test package's *-tests.jar file.Note: In Device Farm's standard test environment, only a subset of the features in the testng.xml file are supported. Use the custom test environment if your project requires any of the following testng.xml file features:Priority'include' and 'exclude' tagsComplex groupingAny TestNG parameters defined in your testng.xml fileResolution1.    In your Apache Maven pom.xml file, verify that the testResources tag includes the following directory: src/test/resources. If you don't see the directory, add the following directory configuration to the file:<testResources>     <testResource>        <directory>${project.basedir}/src/test/resources</directory>     </testResource></testResources>Note: You can specify another directory to use for this procedure. If you choose to use another directory, make sure that you use that same directory in steps 2 and 3.2.    Add your testng.xml file to your pom.xml file's src/test/resources directory.3.    (Optional) To run tests locally, add the following Maven Surefire plugin to your pom.xml file's <plugins> list.<plugin>    <groupId>org.apache.maven.plugins</groupId>     <artifactId>maven-surefire-plugin</artifactId>    <version>2.12.4</version>     <configuration>       <suiteXmlFiles> <suiteXmlFile>src/test/resources/testng.xml</suiteXmlFile></suiteXmlFiles>    </configuration></plugin>Note: It's a best practice to run tests locally before uploading projects to Device Farm. The Maven Surefire plugin allows your pom.xml file to reference your testng.xml file during local tests.4.    Clean your pom.xml file's target directory and repackage your test files by running the following Maven command:$ mvn clean package -DskipTests=trueNote: The DskipTests=True value specifies that the build won't run the unit tests.The command creates a zip-with-dependencies.zip file in your pom.xml file's target directory. This zip file is your Appium test package and includes your testng.xml file in the root of its *-tests.jar file.5.    Verify that your testng.xml file is in the root of your Appium test package's *-tests.jar file by running one of the following commands:To see a snapshot of files in your *-tests.jar file, run the following jar command:$ jar tvf foo-1.0.0-SNAPSHOT-tests.jar-or-To extract all of the files in your *-tests.jar file into a folder, run the following unzip command:$ unzip foo-1.0.0-SNAPSHOT-tests.jar -d sampletestsjarcontentsYou can now upload your test package to Device Farm and create a test run using your app and the zip-with-dependencies.zip file.Related informationTroubleshooting Appium Java TestNG web applications in AWS Device FarmWorking with custom test environments in AWS Device FarmFollow"


Question: How can I allow a secondary account to push or pull images in my Amazon ECR image repository?

I want to allow a secondary account to push or pull images in my Amazon Elastic Container Registry (Amazon ECR) image repository.

Answer: "I want to allow a secondary account to push or pull images in my Amazon Elastic Container Registry (Amazon ECR) image repository.ResolutionYou can push or pull images to or from an Amazon ECR repository in another account. First, you must create a policy that allows the secondary account to perform API calls against the repository. Then, use a Docker authentication token generated from the secondary account to use push and pull commands against the primary account's repository.Create a policy that allows the secondary account to perform API calls against the image repository1.    Open the Amazon ECR console for your primary account.2.    Choose the hyperlinked Repository name of the repository that you want to modify.3.    From the left navigation pane, under Amazon ECR - Repositories, choose Permissions.4.    To add a repository policy for your secondary account from within your primary account, choose Edit policy JSON. Enter your policy into the code editor, and then choose Save.Important: In your policy, include the account number of the secondary account and the actions that the account can perform against the repository. To allow access to a specific role, provide the role arn as the principal. For example, AWS: arn:aws:iam::account-id:role/ecsInstanceRole. The role must exist in the secondary account before you save the repository policy. If it doesn't exist, then you receive an error similar to the following: invalid repository policy provided.The following example repository policy allows a specific account to push and pull images:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "AllowPushPull",      "Effect": "Allow",      "Principal": {        "AWS": "arn:aws:iam::account-id:root"      },      "Action": [        "ecr:GetDownloadUrlForLayer",        "ecr:BatchGetImage",        "ecr:BatchCheckLayerAvailability",        "ecr:PutImage",        "ecr:InitiateLayerUpload",        "ecr:UploadLayerPart",        "ecr:CompleteLayerUpload"      ]    }  ]}5.    In the task definition, set the image that you want to use with Amazon ECS. Your image is hosted in the primary account's Amazon ECR repository.Note: Make sure that your secondary account has Amazon ECR permissions listed in "AmazonEC2ContainerRegistryPowerUser" managed policy. These permissions are required to pull or push from your primary account.Generate a temporary Docker authentication token from the secondary account and perform a test push or pullNote: 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.The secondary account can't perform policy actions on the repository until it receives a temporary authentication token that's valid for 12 hours. The token allows the secondary account to use Docker push and pull commands against the primary account's repository. The get-login-password command retrieves and decodes the authorization token that you can then pipe into a docker login command to authenticate.Note: The account that gets the token must have the relevant AWS Identify and Access Management (IAM) API permissions to modify the repository. For examples, see AWS managed policies for Amazon Elastic Container Registry. To troubleshoot issues with Docker, turn on debug mode on your Docker daemon. This command is supported using the latest version of AWS CLI version 2, or in v1.17.10 or later of AWS CLI version 1. For more information, see get-login-password.1.    To generate a Docker authentication token for an account that pushes and pulls images outside of Amazon ECS, run the following command. Replace aws_account_id with your primary account ID, and replace regionID with your Region ID.Using the AWS CLI:aws ecr get-login-password --region regionID | docker login --username AWS --password-stdin aws_account_id.dkr.ecr.regionID.amazonaws.comUsing AWS Tools for Windows PowerShell:(Get-ECRLoginCommand).Password | docker login --username AWS --password-stdin aws_account_id.dkr.ecr.regionID.amazonaws.comYou receive the following output:aws ecr get-login-password --region ap-south-1 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.ap-south-1.amazonaws.comWARNING! Your password will be stored unencrypted in /root/.docker/config.json.Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credentials-store    Login Succeeded2.    Perform a test image pull from or push to the primary account:docker pull AccountID.dkr.ecr.Region.amazonaws.com/ImageName::TagNameNote: Replace AccountID and Region with your account ID and Region. Replace ImageName and TagName with the name of your image and tag.3.    Validate that the image downloaded successfully:docker images | grep ImageNameNote: Replace ImageName with the name of your image.Follow"


Question: How do I troubleshoot Elastic Load Balancing "Connection timed out" errors?

I'm using Elastic Load Balancing (ELB) and receiving a "Connection timed out" error. How do I troubleshoot a connection timeout between my load balancer and a client?

Answer: "I'm using Elastic Load Balancing (ELB) and receiving a "Connection timed out" error. How do I troubleshoot a connection timeout between my load balancer and a client?ResolutionVerify that your load balancer scheme is internet-facingIf the client is trying to connect over the internet, verify that the ELB scheme is internet-facing.Confirm that a listener is configured for the load balancer portVerify the configuration of the listeners for your load balancer port that the client connects to:Listeners for your Application Load Balancers (ALB)Listeners for your Classic Load Balancers (CLB)Listeners for your Network Load Balancers (NLB)Confirm that the security groups for your target instances allow trafficApplication Load Balancers and Classic Load BalancersCheck the settings of the security group attached to the load balancer. Confirm that traffic is allowed in both directions for the listener and health check ports. For more information, see Security groups for your Application Load Balancer and Configure security groups for your Classic Load Balancer.Network Load BalancersIf you register EC2 instances as targets, confirm that the security groups for these instances allow traffic on both the listener and health check ports. If you register targets by IP address, then be sure that the security group for the targets allows traffic from the NLB nodes. For more information, see Register targets with your target group (Network Load Balancer).If you're using Client IP preservation, confirm that the target security group allows traffic from the client IP addresses. For more information, see Client IP preservation.Verify that the network ACL allow the required trafficVerify that the network access control list (network ACL) associated with the subnets where load balancer nodes are present:Allows access on the port being accessedAllows access to particular client IP addresses in the inbound rules.Network ACLs are stateless, so you must allow access in both inbound and outbound rules. Also confirm that all the ephemeral ports are allowed in your outbound rules. Allowing only some ephemeral ports can lead to intermittent connection issues. For more information, see Network ACLs for load balancers in a VPC.Confirm that route tables are configured correctlyFor internet-facing load balancers, confirm that the route tables associated with the subnets where load balancer nodes are present has an internet gateway.For internal load balancers using a private connection to the load balancer, there might be multiple route tables associated with different subnets. Connectivity issues can occur on individual nodes, causing intermittent issues. Check the route tables associated with all nodes. If connectivity fails for a node, then verify that the route table associated with the load balancers node subset is configured. Add routes as required.Use the following command to test node connectivity:nc –v <ELB IP Address> <Port>telnet <ELB IP Address> <Port>Note: Enter your information for ELB IP Address and Port.Verify that the client isn't connecting to a terminated node (Application Load Balancer and Classic Load Balancer)Confirm that the client isn't connecting to an Application Load Balancer or Classic Load Balancer node that is terminated. Verify that the client's IP addresses is included on the list of current IP addresses published in the ELB Domain Name System (DNS). Run the following dig command using your domain name for example.com:$ dig +short example.com35.154.42.22913.126.64.179Confirm that a client-side firewall isn't blocking trafficIf other troubleshooting methods don't resolve your connectivity issues, then a client-side firewall might be blocking traffic. To troubleshoot the issue, follow these steps:If you're using VPC Flow Logs with metadata, check the logs of the load balancer node interfaces. Confirm that the SYN from the client IP address is received by the load balancer. Then, confirm that the SYN, ACK is sent back by the load balancer node to the client IP address. If SYN, ACK isn't returned from the load balancer node, then there might be an issue with that node. For an example of how to read flow logs, see TCP Flag sequence.Take a packet capture on the machine that's running the client. Use the tcpdump utility to get network traffic for analysis. If the connection fails, update your firewall rules to allow the required traffic.Related informationTroubleshoot your Application Load BalancerTroubleshoot your Classic Load BalancerCustom network ACLsFollow"


Question: How do I set up an HTTP proxy for Docker and the Amazon ECS container agent in Amazon Linux 2?

I want to set up an HTTP proxy for Docker and the Amazon Elastic Container Service (Amazon ECS) container agent in Amazon Linux 2.

Answer: "I want to set up an HTTP proxy for Docker and the Amazon Elastic Container Service (Amazon ECS) container agent in Amazon Linux 2.Short descriptionTo set up an HTTP proxy for Docker and the Amazon ECS container agent in Amazon Linux 2, complete the steps in the following sections:Store the IP address and proxy server portSet up an HTTP proxy for the Docker daemonSet up an HTTP proxy for the Amazon ECS container agentSet up an HTTP proxy for ecs-initNote: You can also set your environment variables during launch using Amazon Elastic Compute Cloud (Amazon EC2) user data with a user data script. For a user data script that works on all versions of Linux, see HTTP proxy configuration.If you're using Amazon Linux, see How do I set up an HTTP proxy for Docker and the Amazon ECS container agent in Amazon Linux?ResolutionStore the IP address and proxy server port1.    Connect to the Amazon EC2 instance using SSH.2.    As a root user, store the IP address and port of the proxy server for later use in environment variables. For example:export PROXY_SERVER_IP=x.x.x.xexport PROXY_PORT=1234Set up an HTTP proxy for the Docker daemon1.    Run the following commands with sudo permissions:mkdir /etc/systemd/system/docker.service.dcat <<EOF > /etc/systemd/system/docker.service.d/http-proxy.conf[Service]Environment="HTTP_PROXY=http://$PROXY_SERVER_IP:$PROXY_PORT"Environment="HTTPS_PROXY=https://$PROXY_SERVER_IP:$PROXY_PORT"Environment="NO_PROXY=169.254.169.254,169.254.170.2"EOFNote: HTTP_PROXY is the socket address (IPaddress:Port) of the HTTP proxy that's used to connect the Amazon ECS container agent to the internet.If the HTTP_PROXY variable is set, you must set the NO_PROXY variable to 169.254.169.254,169.254.170.2. This setting filters Amazon EC2 instance metadata, AWS Identity and Access Management (IAM) roles for tasks, and Docker daemon traffic from the proxy.2.    To reload units because of docker.service changing on disk, run the following command:systemctl daemon-reload3.    To restart Docker, run the following command:systemctl restart docker.serviceNote: The preceding command stops all running containers, including the ecs-agent on the container instance.4.    To verify the HTTP proxy settings for Docker, run the following command:docker info | grep -i proxyNote: The command output shows the HTTP proxy and HTTPS proxy.Set up an HTTP proxy for the Amazon ECS container agent1.    In your /etc/ecs/ecs.config file, include the proxy configuration using the HTTP_PROXY and NO_PROXY agent configuration parameters. For example:cat <<EOF >> /etc/ecs/ecs.configECS_CLUSTER=your-cluster-nameHTTP_PROXY=http://$PROXY_SERVER_IP:$PROXY_PORTNO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sockEOF2.    To apply the HTTP configurations from step 1 to the ecs-agent, run the following command:systemctl restart ecsNote: If you're using an Amazon ECS-optimized Amazon Machine Image (AMI), then the Amazon ECS container agent is run through ecs-init by default.3.    To verify the HTTP proxy settings for Docker and the Amazon ECS container agent, run the following command:docker inspect ecs-agent | grep -i proxyNote: The proxy settings appear in the command output.Set up an HTTP proxy for ecs-init1.    Run the following commands with sudo permissions:mkdir /etc/systemd/system/ecs.service.dcat <<EOF > /etc/systemd/system/ecs.service.d/http-proxy.conf[Service]Environment="HTTP_PROXY=$PROXY_SERVER_IP:$PROXY_PORT/"Environment="NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock"EOF2.    To reload units because of docker.service changing on disk, run the following command:systemctl daemon-reload3.    To apply the HTTP configurations from step 1 to the ecs-agent, run the following command:systemctl restart ecsNote: The configuration for both Docker and the Amazon ECS container agent affects only the current running instance. To update all the instances in a cluster, create a launch configuration, and then use an Auto Scaling group to launch new instances.Related informationUpdating the Amazon ECS container agentBootstrapping container instances with Amazon EC2 user dataFollow"