Question: How do I find out what AWS account a CloudFront distribution belongs to?

I want to locate the AWS account that an Amazon CloudFront distribution belongs to. How can I do this?

Answer: "I want to locate the AWS account that an Amazon CloudFront distribution belongs to. How can I do this?Short descriptionTo find information about an AWS account that a distribution belongs to, use the ListConflictingAliases command to get information about the AWS account.First, create a new CloudFront distribution and associate with an SSL certificate. This SSL certificate must cover the domain associated with the CloudFront distribution whose AWS account you're trying to locate.Then, run the ListConflictingAliases command, using the ID of the new distribution and the alternate domain name associated with the distribution you want to find.Note: To use this method, the distribution must have alternate domain name associated to it. If the CloudFront distribution you are trying to locate does not have an alternate domain name associated, then contact AWS Support.ResolutionCreate a CloudFront distributionCreate a new CloudFront distribution, and be sure to:Associate an SSL certificate that covers the domain associated with the CloudFront distribution whose AWS account you're trying to locate.Don't specify a domain name in Alternate Domain Name. A value in this field causes a "CNAME already exists" error.If you don't want to create a new distribution, you can update an existing CloudFront distribution with a custom SSL certificate.Run the ListConflictingAliases commandNote: The ListConflictingAliases command requires GetDistribution and ListConflictingAliases permissions. To verify ownership, you must have read access to YourDistributionID. You must also have a certificate associated that secures the conflicting CNAME.1.    In the AWS Identity and Access Management (IAM) policy for the distribution that you created, add the following resource-level permissions to the IAM user or role that's making the API request.For DISTRIBUTION-ID, enter the ID of the new distribution you created.{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "CloudFrontCnameSwapCrossAcc",      "Effect": "Allow",      "Action": [                "cloudfront:GetDistribution",                "cloudfront:ListConflictingAliases"      ],      "Resource": [        "arn:aws:cloudfront::123456789:distribution/DISTRIBUTION-ID"      ]    }  ]}2.    Verify that the new distribution has a valid certificate.3.    Run the ListConflictingAliases command:$ aws cloudfront list-conflicting-aliases --distribution-id YourDistributiontID --alias YourCNAMEForYourDistributionId, enter the ID of the new distribution created in your AWS account. ForYourCNAME, enter the alias (alternate domain name) associated with the CloudFront Distribution that you are trying to locate.4.    The output provides a list of CloudFront distributions and the associated account ID that conflicts with the alias that you entered in the ListConflictingAliases command.The domain name in the  --alias parameter is associated with the CloudFront distribution that you are trying to find. The AWS account ID associated with the distribution ID is also listed in the output.For example:$ aws cloudfront list-conflicting-aliases --distribution-id EABCDSXK9UXYZ --alias www.example.com{  "ConflictingAliasesList": {    "MaxItems": 100,    "Quantity": 1,    "Items": [      {        "Alias": "www.example.com",        "DistributionId": "*******NOOCXYZ",        "AccountId": "******091234"      }    ]  }}Note: CloudFront distribution created through  edge-optimized API endpoint in API Gateway or AWS Amplify managed hosting are managed by the AWS Managed Account. In this case, the AWS Account ID in the output is related to the AWS Managed Account. CloudFront distributions created for edge-optimized API endpoint in API Gateway can be identified by a Region-specific API Gateway account ID. For a full list of Region-specific API Gateway account IDs, see Log custom domain name creation in CloudTrail.Follow"


Question: How do I resolve the "unresolved issues with your inputs" error in AWS Batch when I try to delete my compute environment?

"When I try to delete my AWS Batch compute environment, I receive the following error message: "There are unresolved issues with your inputs. Please review the form and try again." How can I resolve this error and delete my compute environment?"

Answer: "When I try to delete my AWS Batch compute environment, I receive the following error message: "There are unresolved issues with your inputs. Please review the form and try again." How can I resolve this error and delete my compute environment?Short descriptionAWS Batch returns an unresolved issues with your inputs error in the following situations:An incorrect AWS Identity and Access Management (IAM) service role causes your compute environment to enter the INVALID state.A resource from a parameter that could only be edited when your compute environment was created no longer exists in your AWS account. For example: A security group.To resolve the error, you must first make sure that your compute environment is in the VALID state. Then, update the compute environment with a new service role that includes the required permissions before deleting the compute environment.ResolutionIf your compute environment is in the INVALID state1.    Follow the instructions in How do I fix an INVALID compute environment in AWS Batch? to move your compute environment into the VALID state.2.    Follow the instructions in the If your compute environment is in the VALID state section of this article.If your compute environment is in the VALID stateNote: 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.1.    Update the compute environment with a new service role that includes the required permissions by running the following update-compute-environment command:Important: Replace your-aws-region with your compute environment's AWS Region. Replace your-compute-environment-arn with your compute environment's Amazon Resource Name (ARN). Replace your-service-role-arn with your AWS Batch service IAM role's ARN.aws --region your-aws-region batch update-compute-environment --compute-environment your-compute-environment-arn --service-role your-service-role-arn2.    Deactivate the compute environment by running the following update-compute-environment command:Important: Replace your-aws-region with your compute environment's AWS Region. Replace your-compute-environment-arn with your compute environment's ARN.aws --region your-aws-region batch update-compute-environment --compute-environment  your-compute-environment-arn --state DISABLED3.    Delete the compute environment by running the following delete-compute-environment command:Important: Replace your-aws-region with your compute environment's AWS Region. Replace your-compute-environment-arn with your compute environment's ARN.aws --region your-aws-region batch delete-compute-environment --compute-environment your-compute-environment-arnFollow"


Question: Why does my instance appear as non-compliant in the Systems Manager Compliance dashboard?

My Amazon Elastic Compute Cloud (Amazon EC2) instance appears as non-compliant in the AWS Systems Manager Compliance dashboard. What is causing this issue?

Answer: "My Amazon Elastic Compute Cloud (Amazon EC2) instance appears as non-compliant in the AWS Systems Manager Compliance dashboard. What is causing this issue?Short descriptionThe Systems Manager Compliance capability provides compliance data for your fleet of managed instances. The compliance status of a managed instance is determined to be compliant or non-compliant based on the following factors:The status of Patch Manager patchingThe status of State Manager associationsIf applicable, the status of custom compliance itemsTo determine the compliance status of an instance, you can view the configuration compliance report. When reviewing the compliance report, identify the Compliance Type for each non-compliant instance.Compliance Type Patch indicates that the instance is non-compliant due to Patch Manager patching.Compliance Type Association indicates that the instance is non-compliant due to State Manager associations.Note: The prerequisites to get started with Compliance must be met before Systems Manager Compliance can begin reporting compliance data.ResolutionNon-compliance based on the status of Patch Manager patchingAn instance can appear as non-compliant based on Patch Manager patching for the following reasons:AWS-RunPatchBaseline document didn't run on the instanceThe AWS-RunPatchBaseline document using the Install operation didn't run on the instance after patches were approved according to the instance patch baseline document settings. Follow these steps to resolve the issue:View the configuration compliance report. Choose the Patch tab, and then review the Patch Summary. If Updates Needed is anything other than 0, your instance is non-compliant because one or more approved patches must be installed.To determine the patches that must be installed, scroll down, select the search bar, and look for patches with the state set to Missing.Note: Each patch in your managed instance is assigned a compliance state value. The value determines the compliance status of that instance.Run the AWS-RunPatchBaseline document using the Install operation on the non-compliant instance. You can start the patching operation using the Patch now option in the Patch Manager console. Or, you can run the AWS-RunPatchBaseline document either using Run Command or as part of a maintenance window.AWS-RunPatchBaseline document ran, but some approved patches failed to installThe AWS-RunPatchBaseline document using the Install operation ran on the instance. However, some of the approved patches failed to install on the instance for reasons specific to the instance. Follow these steps to identify the instance-specific issue:View the configuration compliance report. Choose the Patch tab, scroll down, select the search bar, and look for patches with the state set to Failed.Note the failed patches, and then log in to your instance using SSH or Session Manager.Review the SSM Agent logs in the instance and the specific operation logs to identify any instance-specific issues.Linux-based instances:/var/log/amazon/ssm/amazon-ssm-agent.log/var/lib/amazon/ssm/InstanceID/document/orchestration/CommandIDWindows-based instances:%PROGRAMDATA%\Amazon\SSM\Logs\amazon-ssm-agent.log%PROGRAMDATA%\Amazon\PatchBaselineOperationsNote: Look for a log file named Install-PatchBaselineOperation-dateNote: Patch Manager doesn't provide patches. Instead, Patch Manager orchestrates patching by` using the appropriate built-in mechanism for each operating system (OS) to install updates on an instance. For example, Patch Manager relies on Windows Update to install patches on instances running Microsoft Windows. Similarly, Patch Manager relies on yum for instances running Amazon Linux 2.AWS-RunPatchBaseline document ran, but the RebootOption parameter is set to NoRebootThe AWS-RunPatchBaseline document using the Install operation ran on the instance, and all approved patches were successfully installed. However, the RebootOption parameter in the AWS-RunPatchBaseline document is set to NoReboot. Follow these steps to resolve the issue:View the configuration compliance report. Choose the Patch tab, scroll down, select the search bar, and look for patches with the state set to InstalledPendingReboot.Note: The InstalledPendingReboot state holds the instance in non-compliant state until the instance is rebooted and scanned.Reboot the instance.Scan the instance and verify that the instance appears as compliant in the Systems Manager Compliance dashboard.AWS-RunPatchBaseline document ran, but some rejected patches were present on the instanceThe AWS-RunPatchBaseline document using the Install operation ran on the instance, and all approved patches were successfully installed. However, some rejected patches were also present on the instance. Follow these steps to resolve the issue:View the configuration compliance report. Note the Association ID that corresponds to the non-compliant association type for later use.Choose the Patch tab, scroll down, select the search bar, and look for patches with the state set to InstalledRejected.Note: The InstalledRejected state indicates that a patch was installed before it was added to a list of rejected patches.Note the rejected patches, and then log in to your instance using SSH or Session Manager.Remove any rejected patches.Non-compliance based on the status of State Manager associationsWhen a Systems Manager State Manager association is created, a configuration state is defined for the instance. If that state isn't maintained, then the Systems Manager Compliance dashboard reports the instance as non-compliant. Follow these steps to resolve the issue:View the configuration compliance report. Note the Association ID that corresponds to the non-compliant association type for later use.From the Systems Manager console, view the association history.Review the output to understand the reason for the failed association. For more information, see How can I troubleshoot a State Manager association that failed or that is stuck in pending status?AWS-GatherSoftwareInventory document issuesIf your instance is non-compliant due to issues running the AWS-GatherSoftwareInventory document, then troubleshoot common problems with Systems Manager Inventory.Follow"


Question: How do I request an AWS Health event for testing integration with AWS Health?

I want to use an AWS Health event to test integration with AWS Health.

Answer: "I want to use an AWS Health event to test integration with AWS Health.ResolutionIf you have a Developer, Business or Enterprise Support plan, then you can open a technical support case to request an AWS Health test event. You can then use this AWS Health event for testing purposes with the AWS Health service.Note: If you have a Basic Support plan, then you can upgrade your Support plan. For more information, see How do I change my AWS Support plan?1.    Open the AWS Support Center. Or, in the AWS Management Console, choose the question mark icon, and then choose Support Center.2.    Choose Create case, choose Technical, and then choose Next step: Additional information.3.    Choose the Service dropdown list, and then choose Health.4.    Choose the Category as Other, and the Severity as General guidance.5.    Enter the following information in the case details:A brief overview of the solution being testedThe date for when you want AWS to create the test eventThe AWS Region for the eventThe event type categoryThe event start time (the time that the event begins or began)The event end time (the time that the event ends or ended)6.    Choose Submit.Related informationWhat is AWS Health?Follow"


Question: How does WorkSpaces manage operating system updates for Windows?

I need more information about how Amazon WorkSpaces manages operating system (OS) updates for Windows. What do I need to know?

Answer: "I need more information about how Amazon WorkSpaces manages operating system (OS) updates for Windows. What do I need to know?ResolutionWindows WorkSpaces are configured to download and install updates and patches during default maintenance windows. The running mode for your WorkSpace determines its default maintenance windows. As a best practice, keep Windows Update active in your WorkSpaces.Note: The default time zone for a WorkSpace is the same as its AWS Region.AlwaysOn WorkSpaces maintenance windows for updates and patchesThe default maintenance window for AlwaysOn WorkSpaces OS updates is a 4-hour time period each week. Updates can run each Sunday from 00h00–04h00 in the time zone set for the WorkSpace. When time zone redirection is turned on, the time zone of the WorkSpace is updated when a user connects from another Region.Note: To learn more about turning off time zone redirection, see Turn off time zone redirection for PCoIP and Turn off time zone redirection for WSP.AutoStop WorkSpaces maintenance windows for updates and patchesThe default maintenance window for AutoStop WorkSpaces OS updates is a 5-hour time period each day for up to 2 weeks each month. OS updates can run starting the third Monday of the month and can run on any day during the 2-week maintenance window. Updates can run from 00h00–05h00 in the time zone set for the WorkSpace.Microsoft releases software patches on the second Tuesday of each month. AutoStop WorkSpaces scan for and install any software patches on any day during the 2-week maintenance window.Additional update considerationsWhen you set up customizations through group policy, you might restrict or control Windows updates. You need to configure Windows OS update settings for maintenance windows to function in WorkSpaces.For PColP and other WorkSpace components, the system scans for updates during maintenance windows. Updates are pushed upon each reboot.For more information about settings that can affect Windows updates, see Manage Windows WorkSpaces.You can manage Windows updates for WorkSpaces by configuring a Windows Server Update Server (WSUS Server). When a WorkSpace has no outbound internet access, configuring a WSUS server is the only way to update the WorkSpace.For more information, see Deploy Windows Server Update Services on the Microsoft website.If you prefer, you can temporarily change your WorkSpace state to Maintenance so that you can manually perform OS maintenance tasks.For more information about changing your WorkSpace state to perform maintenance, see Manual maintenance.Related informationWorkSpace maintenanceBest practices for deploying Amazon WorkSpacesFollow"


Question: How do I resolve the "Role [role_arn] is invalid or cannot be assumed” error when I update or delete an AWS CloudFormation stack?

"I want to resolve the "Role [role_arn] is invalid or cannot be assumed” error when I create, update, or delete an AWS CloudFormation stack."

Answer: "I want to resolve the "Role [role_arn] is invalid or cannot be assumed” error when I create, update, or delete an AWS CloudFormation stack.Short descriptionYou receive this error when there's an issue with the AWS Identity and Access Management (IAM) service role that's used by AWS CloudFormation to make calls to resources in a stack on your behalf.You can receive this error when you try to:Create a stack using the AWS Command Line Interface (AWS CLI) or an API call.Update a stack when AWS CloudFormation creates a change set.Delete a stack.Update or delete an IAM role. If you modify the trust policy of an updated IAM role, then AWS CloudFormation can't assume the role.To resolve this error, determine if IAM service role that's used by AWS CloudFormation exists. Then:If the IAM role doesn't exist, create a new IAM role with the same name.If the IAM role exists, confirm that the role trust policy allows AWS CloudFormation to assume the IAM role.Or, you can override the current IAM role used to override the service role used for the current stack operation using the --role-arn parameter.Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.ResolutionConfirm that the IAM role exists1.    Open the IAM console.2.    In the navigation pane, choose Roles.3.    In the Role name column, choose the IAM role that's mentioned in the error message that you received.4.    If the role exists, complete the steps in the Confirm that the role trust policy allows AWS CloudFormation to assume the IAM role section-or-Complete the steps in the Override the current IAM role used by AWS CloudFormation.        If the role doesn't exist, complete the steps in the Create a new IAM role and confirm it has the required permissions.Create a new IAM role and confirm it has the required permissions1.     Create a new IAM role with the same name as the role mentioned in the error2.    Confirm that the new IAM role has the required permissions for AWS CloudFormation to perform create, update, or delete operations on resources in your stack.3.    After the role is created, you can create, update, or delete your stack again.Note: If the new role doesn't have the required IAM permissions, then the stack operations could fail. For example, the delete operation fails if you try to delete an Amazon Elastic Compute Cloud (Amazon EC2) instance resource where the IAM role doesn't have the permission for the ec2:TerminateInstances action.Confirm that the role trust policy allows AWS CloudFormation to assume the IAM role1.    Open the IAM console.2.    In the navigation pane, choose Roles.3.    In the Role name column, choose the IAM role that's mentioned in the error message that you received.4.    Choose the Trust relationships tab.5.    Confirm that the trust relationship shows cloudformation.amazonaws.com as a trusted entity.If cloudformation.amazonaws.com isn't listed as a trusted entity, then choose Edit trust relationship.6.    In the Policy Document editor, enter the following AWS CloudFormation service role trust policy:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "",      "Effect": "Allow",      "Principal": {        "Service": "cloudformation.amazonaws.com"      },      "Action": "sts:AssumeRole"    }  ]}7.    Choose Update Trust Policy.Now, the updated trusty policy allows AWS CloudFormation to assume the IAM role.8.    After the role is created, you can create, update, or delete your stack again.Override the current IAM role used by AWS CloudFormation1.    To update the stack, run the following command:aws cloudformation update-stack --stack-name my-stack --template-body file://my-stack-template.json --role-arn arn:aws:iam::123456789123:role/cloudformation-roleNote: Replace my-stack, my-stack-template.json, and 123456789123 with your values.2.    To delete the stack, run the following command:aws cloudformation delete-stack --stack-name my-stack --role-arn arn:aws:iam::123456789123:role/cloudformation-roleNote: Replace my-stack and 123456789123 with your values.Related informationAWS CloudFormation service roleCreating a role to delegate permissions to an AWS serviceFollow"


Question: How do I troubleshoot packet loss on my VPN connection?

I'm having continuous or intermittent packet loss and high latency issues on my VPN connection. I want to run tests to be sure that the issue isn't taking place inside my Amazon Virtual Private Cloud (Amazon VPC).

Answer: "I'm having continuous or intermittent packet loss and high latency issues on my VPN connection. I want to run tests to be sure that the issue isn't taking place inside my Amazon Virtual Private Cloud (Amazon VPC).ResolutionBefore beginning performance tests, launch and configure your Amazon Elastic Compute Cloud (Amazon EC2) Linux instances:Follow the steps in Launch an instance to launch Linux instances in at least two different Availability Zones under the same VPC. You can run network performance testing from the instance.For the best possible network performance, be sure that the instances support enhanced networking for Linux and launch the instances in the same VPC.If you're performing network testing between instances that aren't co-located in the same placement group or don't support jumbo frames, follow the steps to Check and set the MTU on your Linux instance.Complete the steps in Connect to your Linux instance to verify that you can access the instances.Use mtr to check for ICMP or TCP packet loss and latencyInstall the mtr network tool on both instances to check for any ICMP or TCP packet loss and latency. mtr provides continually updated output that allows you to analyze network performance over time. It combines the functionality of traceroute and ping in a single network diagnostic tool.Install mtr on Amazon Linux:sudo yum install mtrInstall mtr on Ubuntu:sudo apt-get install mtrRun the following tests between the private and public IP address of your EC2 instances and your on-premises host bidirectionally. The path between nodes on a TCP/IP network can change when the direction is reversed. Note: it's important to obtain mtr results in both directions.The first mtr test is ICMP-based, but the second test has a -T option, which gives you a TCP-based result. The TCP-based result helps you determine if there is any application-based packet loss or latency on the connection. MTR version 0.85 and above has the TCP option.Private IP tests:mtr -n -c 200 <Private IP EC2 instance/on-premises host> --reportmtr -n -T -c 200 <Private IP EC2 instance/on-premises host> --reportPublic IP tests:mtr -n -c 200 <Public IP EC2 instance/on-premises host> --reportmtr -n -T -c 200 <Public IP EC2 instance/on-premises host> --reportUse the Linux traceroute utility to determine latency or routing problemsThe Linux traceroute utility identifies the path that is taken from a client node to a specified destination node. It also shows the time in milliseconds for each router identified in the path to respond to a request. And, this utility calculates and displays the amount of time each hop takes before reaching its destination. If traceroute isn't installed, make sure to install it on your instance.Install traceroute on Amazon Linux:sudo yum install tracerouteInstall traceroute on Ubuntu:sudo apt-get install tracerouteRun the following tests between the private and public IP address of your EC2 instances and your on-premises host bidirectionally. The path between nodes on a TCP/IP network can change when the direction is reversed. It's important to obtain trace route results in both directions.Private IP tests:sudo traceroute <private IP of EC2 instance/on-premises host>sudo traceroute -T -p 80 <private IP of EC2 instance/on-premises host>Public IP tests:sudo traceroute <public IP of EC2 instance/on-premises host>sudo traceroute -T -p 80 <public IP of EC2 instance/on-premises host>Note: The arguments -T -p 80 -n perform a TCP-based trace on port 80. Be sure that you have port 80 or the port that you are testing with open in both directions.The Linux traceroute option to specify a TCP-based trace instead of ICMP is useful because most internet devices deprioritize ICMP-based trace requests. A few timed-out requests are common, so watch for packet loss to the destination or in the last hop of the route. Packet loss that accumulates over several hops can also indicate a problem.Note: When troubleshooting network connectivity using traceroute, it's helpful to run the command in both directions.Use hping3 to determine latency or TCP packet loss problemshping is a command-line oriented TCP/IP packet assembler/analyzer. In addition to ICMP echo requests, it supports TCP, UDP, and RAW-IP protocols. It also has a traceroute mode, the ability to send files between a covered channel, and many other features.If hping3 isn't installed, run the following command on Amazon Linux:sudo yum --enablerepo=epel install hping3Then, run the following commands:hping3 -S -c 50 -V <Public IP of EC2 instance or on-premises host>hping3 -S -c 50 -V <Private IP of EC2 instance or on-premises host>Note: By default, hping3 sends TCP headers to the target host's port 0 with a winsize of 64 without any tcp flag on.Packet capture samples using tcpdumpYou can perform packet captures on both your EC2 instances (present in multiple Availability Zones) and your on-premises host when duplicating issues. These packet capture samples help determine if there are any network layer issues on the VPN connection. Install tcpdump on your instance to perform packet captures.Install tcpdump on Amazon Linux:sudo yum install tcpdumpInstall tcpdump on Ubuntu:sudo apt-get install tcpdumpNote: Refer to your specific vendor documentation for instructions on how to check network devices for analysis and troubleshooting.Related informationHow do I benchmark network throughput on an Amazon EC2 Linux instance in the same Amazon VPC?Follow"


Question: How can I change the ownership of publicly (anonymously) owned objects in my Amazon S3 bucket?

My Amazon Simple Storage Service (Amazon S3) bucket has an object with public (anonymous) ownership. How can I change the object's ownership so that my AWS account owns the object?

Answer: "My Amazon Simple Storage Service (Amazon S3) bucket has an object with public (anonymous) ownership. How can I change the object's ownership so that my AWS account owns the object?Short descriptionBy default, an Amazon S3 object is owned by the identity that uploaded the object. This means that if you allow public write access to your bucket, the objects uploaded by public (anonymous) users are publicly owned. To prevent security issues, the best practice is to block public access to your bucket.If an object was already uploaded to your bucket by an anonymous user and you want to change object ownership, then modify the object's ACL. Change the object's ACL to grant the bucket owner (your AWS account) full control of the object.Note: You can also use Amazon S3 Object Ownership to control ownership of objects uploaded by another AWS account.ResolutionFollow these steps to change the object's ownership to the AWS account that owns the bucket:1.    To add an object ACL, run the put-object-acl command using the AWS Command Line Interface (AWS CLI). Include the --acl option with the value bucket-owner-full-control to add an ACL that grants the bucket owner control of the object. Then, include the --no-sign-request option to use anonymous credentials for the request. The full put-object-acl command with the options that you need is similar to the following:aws s3api put-object-acl --bucket DOC-EXAMPLE-BUCKET --key awsexampleobject  --acl bucket-owner-full-control   --no-sign-requestNote: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.2.    To apply the ownership change, you must copy the object over itself. To do this, run the cp command, similar to the following:aws s3 cp s3://DOC-EXAMPLE-BUCKET/awsexampleobject  s3://DOC-EXAMPLE-BUCKET/awsexampleobject --storage-class STANDARDNote: Make sure to change the --storage-class value in the example command to the storage class applicable to your use case. Additionally, make sure to include other cp command options that you need for your object.3.    To check the ownership change, run the get-object-acl command, similar to the following:aws s3api get-object-acl --bucket DOC-EXAMPLE-BUCKET --key awsexampleobjectThe command returns an output that displays the object's owner, similar to the following:{    "Owner": {        "DisplayName": "jane",        "ID": "75050348ef85628a0977bexamplebdbc3062ce76f35cb463345ae65c2608d099"    },    "Grants": [        {            "Grantee": {                "DisplayName": "jane",                "ID": "75050348ef85628a0977bexamplebdbc3062ce76f35cb463345ae65c2608d099",                "Type": "CanonicalUser"            },            "Permission": "FULL_CONTROL"        }]}4.    If versioning is enabled on the bucket, then you must also delete the previous version of the object generated from the cp command in step 2. The previous object version has public (anonymous) ownership. To delete this object version, first run the list-object-versions command on the bucket. Include the --prefix option of the command to filter the results to the object that had public ownership:aws s3api list-object-versions --bucket DOC-EXAMPLE-BUCKET --prefix example.txtFrom the command output, copy the version ID of the object version that had public ownership. Then, run the delete-object command for the version ID that you want to delete:aws s3api delete-object --bucket DOC-EXAMPLE-BUCKET --key example.txt --version-id 'example.d6tjAKF1iObKbEnNQkIMPjj'Warning: Review the version ID carefully to be sure that it is the version ID of the object version with public ownership. If you delete an object version, it can't be retrieved.Related informationHow do I ensure that I take ownership of new objects?Security best practices for Amazon S3Why can't I access an object that was uploaded to my Amazon S3 bucket by another AWS account?Follow"


Question: How can I use CloudWatch Agent to monitor my Lightsail instance's disk and memory metrics?

I have an Amazon Lightsail instance. How can I use Amazon CloudWatch Agent to monitor my instance's disk and memory metrics?

Answer: "I have an Amazon Lightsail instance. How can I use Amazon CloudWatch Agent to monitor my instance's disk and memory metrics?Short descriptionYou can use CloudWatch to monitor your Lightsail instance's disk utilization and memory metrics. After setup and configuration, these metrics are available in the CloudWatch console, not in the Lightsail dashboard.Note: It's a best practice to create a snapshot of your instance as a backup before making changes to your instance.ResolutionThis resolution uses the AWS Command Line Interface. Amazon Linux 2 comes with the AWS CLI installed. For other distributions, you must install and configure the AWS CLI. If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.Set up CloudWatch Agent to monitor usage on your instance1.    Follow steps 1-4 in Monitoring memory usage in Lightsail instances.2.    Generate the CloudWatch configuration file. The CloudWatch configuration file is a JSON file that specifies the metrics and logs that the agent will collect, including custom metrics. There are two methods for doing this:Method A: Generate the CloudWatch configuration file manually.Method B: Generate the CloudWatch configuration file using the wizard.Method A: Generate the CloudWatch configuration file manuallyFor instructions, see step 5. Create CloudWatch configuration file to collect memory usage metrics in Monitoring memory usage in Lightsail instances. The example shown is specific to capturing memory usage metrics.For more information, see Manually create or edit the CloudWatch agent configuration file.Method B: Generate the CloudWatch configuration file using the wizardRun the following command:$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizardThe wizard asks a series of questions. Select your answers based on your specific requirements. To set up instance monitoring, you can select the default answer for all of the questions with the exception of the following:Are you using EC2 or On-Premises hosts? 1. EC22. On-Premises default choice: [1]: 2Do you want to turn on StatsD daemon? 1. yes 2. no default choice: [1]: 2 Do you want to monitor metrics from CollectD? 1. yes 2. no default choice: [1]: 2 Do you want to monitor cpu metrics per core? Additional CloudWatch charges may apply. 1. yes 2. no default choice: [1]: 2 Do you want to add ec2 dimensions (ImageId, InstanceId, InstanceType, AutoScalingGroupName) into all of your metrics if the info is available? 1. yes 2. no 2default choice: [1]: 2 Do you want to monitor any log files? 1. yes 2. no 2default choice: [1]: 2 Do you want to store the config in the SSM parameter store? 1. yes 2. no default choice: [1]: 23.    Follow steps 6-8 in Monitoring memory usage in Lightsail instances.Note: If you can't see the metrics on the Amazon CloudWatch console, then check the log file at /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log for authentication or credential errors. For more information about the log files and troubleshooting steps, see The CloudWatch Agent won't start.Viewing metrics in CloudWatchAfter completing the preceding steps, wait a few minutes. Then, open the CloudWatch dashboard in the CloudWatch console, switch to the correct Region, and view the Metrics section. View the section labeled CWAgent under Custom Namespaces. The disk_used_percent for root volume xvda1 in the device, fstype, host, and path section appear. Under the host section you can see the memory (RAM) utilization percent for your Lightsail instance.Related informationConnecting to your Linux or Unix instance in LightsailCreate IAM users to use with the CloudWatch agent on on-premises serversDownload and configure the CloudWatch agent using the command lineCreate the CloudWatch agent configuration fileFollow"


Question: How do I encrypt Amazon RDS snapshots using a KMS key?

"I've enabled encryption on an unencrypted Amazon Relational Database Service (RDS) instance, and I want to take an encrypted snapshot of that instance. How do I take an encrypted snapshot of my RDS instance?"

Answer: "I've enabled encryption on an unencrypted Amazon Relational Database Service (RDS) instance, and I want to take an encrypted snapshot of that instance. How do I take an encrypted snapshot of my RDS instance?ResolutionYou can't take an encrypted snapshot of an unencrypted DB instance. However, you can perform a workaround that achieves the same results. The following steps are applicable to Amazon RDS for MySQL, Oracle, SQL Server, PostgreSQL, or MariaDB.Important: If you use Amazon Aurora, you can restore an unencrypted Aurora DB cluster snapshot to an encrypted Aurora DB cluster. However, you must specify an AWS Key Management Service (AWS KMS) encryption key when you restore from the unencrypted DB cluster snapshot. For more information, see Limitations of Amazon RDS encrypted DB instances.1.    Open the Amazon RDS console, and then choose Snapshots from the navigation pane.2.    Select the snapshot that you want to encrypt.3.    Under Snapshot Actions, choose Copy Snapshot.4.    Choose your Destination Region, and then enter your New DB Snapshot Identifier.5.    Change Enable Encryption to Yes.6.    Select your AWS KMS Key from the list.7.    Choose Copy Snapshot.After the snapshot status is available, the Encrypted field is set to "True" to indicate that the snapshot is encrypted. You can now use this encrypted DB snapshot to restore the DB instance from the DB snapshot.Related informationCreating a DB snapshotEncrypting Amazon RDS resourcesFollow"


Question: How can I request a private certificate using the ACM console when ACM-PCA validity period is less than 13 months?

I requested an AWS Certificate Manager (ACM) private certificate but I received a "Failed" error or the certificate status is "Failed". How can I resolve this?


Question: How do I set up an FTP server and an FTP user on my Lightsail instance?

"I want to set up an FTP server and FTP user on my Lightsail instance running Amazon Linux 2, CentOS, Ubuntu or Debian. How can I do this?"

Answer: "I want to set up an FTP server and FTP user on my Lightsail instance running Amazon Linux 2, CentOS, Ubuntu or Debian. How can I do this?ResolutionNote: FTP transmits all data and passwords as plain text. SFTP is a more secure way to connect to your instance and transmit data. For information on using SFTP, see Connecting to your Linux or Unix instance in Amazon Lightsail using SFTP. For information on creating an SFTP user, see How do I create an SFTP user on my Lightsail instance?1.    Run the following command to install the VSFTPD package:Amazon Linux 2 and CentOSsudo yum install vsftpd -yUbuntu and Debiansudo apt install vsftpd -y2.    Edit the vsftpd.config file to change the variables needed for your environment.The vsftpd.config file location varies depending on your operating system:Amazon Linux 2 and CentOS: /etc/vsftpd/vsftpd.confDebian and Ubuntu: /etc/vsftpd.confChange the variables in the following example as needed for your environment:anonymous_enable=NOlocal_enable=YESwrite_enable=YESdirmessage_enable=YESxferlog_enable=YESconnect_from_port_20=NOxferlog_std_format=YESchroot_local_user=YESallow_writeable_chroot=YESchroot_list_file=/etc/vsftpd/chroot_listlisten=YESpam_service_name=vsftpduserlist_enable=YESuserlist_file=/etc/vsftpd/user_listuserlist_deny=NOlisten_port=10021pasv_enable=YESpasv_min_port=21000pasv_max_port=21999pasv_addr_resolve=NONote: Port 21 is the default port for FTP. You can use port 21. However, in the preceding example, for security reasons custom port 10021 is the port for FTP. To customize the port, change the listen_port to the port that you want use and set connect_from_port_20 to NO. Make sure that you activate the ports that you're planning to use for FTP on your instance firewall. For the preceding example, ports 10021 and 21000-21999 are activated on the custom and Lightsail firewall.3.    Run the following command to add the FTP user:sudo adduser --home /home/ftp_user ftp_userNote: In the preceding example, replace ftp_user with a user name of your choice.4.    Run the following command to create a password for the user:sudo passwd ftp_user5.    Run the following command to change the ownership of the /home/ftp_user file. This command makes ftp_user the file owner.sudo chown ftp_user:ftp_user -R /home/ftp_user/6.    Run the following command to add the new user to the vsftpd user_list. Use the -a flag to append to the file.Amazon Linux 2 and CentOSsudo echo "ftp_user" | sudo tee -a /etc/vsftpd/user_listDebian and UbuntuRun the following command to create the userlist file and add the new user to the file:sudo echo "ftp_user" | sudo tee -a /etc/vsftpd.userlist7.    Restart the vsftpd service:sudo systemctl restart vsftpd8.    Connect to the FTP server. The following example uses Filezilla plain FTP.Status:    Connecting to 54.xxx.xxx.x2:10021...Status:    Connection established, waiting for welcome message...Status:    Plain FTP is insecure. Please switch to FTP over TLS.Status:    Logged inStatus:    Retrieving directory listing...Status:    Server sent passive reply with unroutable address. Using server address instead.Status:    Calculating timezone offset of server...Status:    Timezone offset of server is 0 seconds.Status:    Directory listing of "/" successfulStatus:    Connecting to 54.xxx.1xx.52:10021...Status:    Connection established, waiting for welcome message...Status:    Plain FTP is insecure. Please switch to FTP over TLS.Status:    Logged inStatus:    Starting upload of C:\Users\Administrator\Documents\FTPtest.txtStatus:    Server sent passive reply with unroutable address. Using server address instead.Status:    File transfer successful, transferred 10 bytes in 1 secondStatus:    Retrieving directory listing of "/"...Status:    Server sent passive reply with unroutable address. Using server address instead.Status:    Directory listing of "/" successfulTroubleshoot FTP server setupIncorrect options in vsftpd.conf file can cause the vsftpd service go down. If you can't start it, then run the following command to find which options aren't configured correctly:Amazon Linux 2 and CentOSsudo /usr/sbin/vsftpd /etc/vsftpd/vsftpd.confDebian and Ubuntusudo /usr/sbin/vsftpd /etc/vsftpd.confFollow"


Question: How do I update to a newer version of a Node.js solution stack in Elastic Beanstalk?

I receive an error when I try a manual or managed update to a newer version of a Node.js solution stack in AWS Elastic Beanstalk.

Answer: "I receive an error when I try a manual or managed update to a newer version of a Node.js solution stack in AWS Elastic Beanstalk.Short descriptionYour update might fail if your current node version isn't supported by the node version in the solution stack that you're upgrading or downgrading to — that is, the target solution stack.If your update fails, you might receive an error similar to the following:============="Failed Environment update activity. Reason: Configuration validation exception: Invalid option value: '4.8.4' (Namespace: 'aws:elasticbeanstalk:container:nodejs', OptionName: 'NodeVersion'): Value is not one of the allowed values: [4.8.7, 4.9.1, 5.12.0, 6.15.1, 6.16.0, 6.17.0, 6.17.1, 7.10.1, 8.14.0, 8.15.0, 8.15.1, 8.16.0, 8.16.1, 8.16.2, 8.17.0, 10.14.1, 10.15.0, 10.15.1, 10.15.3, 10.16.0, 10.16.1, 10.16.2, 10.16.3, 10.17.0, 10.18.0, 10.18.1, 10.19.0, 12.14.0, 12.14.1, 12.15.0, 12.16.1]".=============To resolve this error, choose one of the following options:To create a new environment, perform a blue/green deployment.To use your existing environment, perform a two-part update based on the steps in the following Resolution section. First, update your Node.js node version, and then update your solution stack.ResolutionImportant: The following steps are valid only for the discontinued Amazon Linux AMI (also called Amazon Linux 1) based solution stacks. For Amazon Linux 2 based solution stacks, the node version can be changed only by creating a new environment of the matching solution stack. For more information on configuring your version of Node.js on Amazon Linux 2 platforms, see Specifying Node.js dependencies with a package.json file.Open the Elastic Beanstalk console.In the navigation pane, choose Environments, and then choose your environment.In the navigation pane section for your environment, choose Configuration.For the Software row in the Category column, choose Edit.For Node.js version, select a node version that's supported by your target solution stack.Important: The node version must be supported by both your current solution stack and target solution stack. For example, if your Elastic Beanstalk environment is running on a 64bit Amazon Linux 2018.03 v4.5.1 running Node.js solution stack with node version 8.11.3, then you can upgrade only to a target solution stack that supports node version 8.11.3. To see what node versions are supported by each type of solution stack, see Node.js platform history.To upgrade or downgrade your node version, choose Apply.Upgrade or downgrade to the platform version of your target solution stack.Follow"


Question: Why is my Amazon RDS DB instance using swap memory when I have sufficient memory?

I'm running an Amazon Relational Database Service (Amazon RDS) DB instance. It's using high amounts of swap memory even though I have enough free memory allocated. Why is swap memory being used when I have sufficient memory?

Answer: "I'm running an Amazon Relational Database Service (Amazon RDS) DB instance. It's using high amounts of swap memory even though I have enough free memory allocated. Why is swap memory being used when I have sufficient memory?Short descriptionAmazon Elastic Compute Cloud (Amazon EC2) instances that run Linux use swap memory when a system requires more memory than is allocated. For more information, see Instance store swap volumes. Because most RDS DB instances use Linux (except SQL Server), your database can sometimes use swap memory.RDS DB instances require pages in the RAM only when the pages are currently accessed, such as when running queries. Other pages that are brought into the RAM by previously run queries are flushed to swap space if they weren't used recently. It's a best practice to let the operating system (OS) swap older pages instead of forcing the OS to keep pages in memory. This makes sure that there is enough free RAM available for upcoming queries.Linux swap usage isn't cleared frequently because clearing the swap usage requires extra overhead to reallocate swap when it's needed and when reloading pages. As a result, if swap space is used on your RDS DB instance, even a single time, the SwapUsage metrics don't return to zero. Swap memory can also be used if you use HugePages that are supported by Amazon RDS for Oracle and  HugePages on Amazon RDS for PostgreSQL. HugePages are larger than the Linux default size of two megabytes.ResolutionTo understand swap usage behavior for your RDS DB instance, first check the DB performance metrics based on the application workload. Check both the FreeableMemory and the SwapUsage Amazon CloudWatch metrics to understand the overall memory usage pattern of your RDS DB instance. Check these metrics for a decrease in the FreeableMemory metric that occurs at the same time as an increase in the SwapUsage metric. This can indicate that there is pressure on the memory of the RDS DB instance. For more information, see How can I troubleshoot low freeable memory in an Amazon RDS for MySQL database? If there is enough freeable memory available, then swap usage shouldn't affect the RDS DB instance's performance. If your freeable memory remains consistently low, you can change your RDS DB instance size to a larger instance size that has more memory.To monitor swap memory, turn on Enhanced Monitoring to review metrics in intervals with a granularity of as little as one second. Enhanced Monitoring collects statistics at the host level, and CloudWatch collects data from the hypervisor level every 60 seconds. Use Enhanced Monitoring to identify increases or decreases that occur for only one second and to see the CPU and memory that are used by individual processes. For more information, see Viewing OS metrics using CloudWatch logs.You can also turn on Performance Insights to identify SQL and wait events that are consuming excessive swap or memory on the RDS DB instance. Performance Insights collects the data at the database level and displays that data in the Performance Insights dashboard. Performance Insights can help you troubleshoot database performance-related issues. For more information, see Monitoring DB load with Performance Insights on Amazon RDS.Amazon RDS for MySQLIf you have low freeable memory, run SHOW FULL PROCESSLIST to review all the threads that are running on your database. The process ID from the output of SHOW FULL PROCESSLIST won't match with the process ID that is displayed by Enhanced Monitoring. To view the correct process ID, modify the DB parameter group that is associated with the database to the Performance_Schema parameter. This is a static parameter, so you must reboot the RDS DB instance. To avoid downtime, modify the parameter and reboot the database outside peak traffic hours. After the memory has reached the desired usage, follow these steps:1.    Sort the process IDs in the Enhanced Monitoring page so that you can see the ID of the processes that are consuming the maximum CPU.2.    Run the following query as the master user:select * from performance_schema.threads where THREAD_OS_ID in (ID shown in the Enhanced Monitoring window)\GFor example, if the max memory is consumed by Thread_OS_Id 10374 and 1432, then run the following query:select * from performance_schema.threads where THREAD_OS_ID in (10374, 1432)\GFor more information, see The threads table on the MySQL website.3.    Get the PROCESSLIST_ID column from the output of this query. This gives you the process ID that matches the value of the process ID from SHOW FULL PROCESSLIST.After you have the correct process ID, you can map the process ID with the query. You can use the ID to identify the root cause of the high memory and CPU usage. You can view the OS process by using Enhanced Monitoring. For more information, see Viewing OS metrics in the RDS console.Amazon RDS for PostgreSQLTo identify the process that is consuming high amounts of memory, map the process ID in the Enhanced Monitoring process list to the exact query. To identify the process, run the following pg_stat_activity view:select * from pg_stat_activity where pid=(the PID of your process);Then, tune the queries to consume less compute resources.Amazon RDS for SQL ServerEnhanced Monitoring might identify a specific thread ID that is consuming high amounts of memory. The thread ID is what SQL Server refers to as the Kernal process ID (KPID).From Amazon RDS for SQL Server, run the following query to get the server process ID (SPID) that corresponds to the KPID:select * from sys.sysprocesses where kpid = '<Value of Thread ID from Enhanced Monitoring>' ;After you have the server process ID, for example 69, run the following command to review what is being done by SPID 69:dbcc inputbuffer(69)Amazon RDS for OracleBy using the OS process ID from Enhanced Monitoring, you can see which process is consuming the most memory. Then, run the following query to get the process address for the session:select ADDR from v$process where SPID=OS_PID;You can use the process address to identify the session inside the database by running the following query:select sid,serial#,username, status from v$session where PADDR='<ADDR from above query>';Related informationOverview of monitoring Amazon RDSFollow"


Question: How do I remove contacts from a callback queue in Amazon Connect?

I want to remove all contacts in my Amazon Connect contact center's callback queue.

Answer: "I want to remove all contacts in my Amazon Connect contact center's callback queue.ResolutionTo remove specific contacts from your callback queue, it's a best practice to use the StopContact API.Note: If you want to remove a contact but don't know the contact ID, then Subscribe to Amazon Connect contact events.If you can't use the StopContact API, then refer to the following options:Manually answer the contacts in the queue.Wait 7–14 days for Amazon Connect to remove the contacts.Deactivate the callback queue. Then, create a new callback queue to replace the deactivated queue. After you create the new callback queue, change the Set working queue parameter to the new queue in the contact flow. For instructions, see Create a flow for queued callbacks. Also, add the new callback queue to your agents' routing profile.Important: If you deactivate the callback queue, then keep the following points in mind:Deactivating the callback queue doesn't remove the contacts from the queue. Deactivating the queue only prevents Amazon Connect from adding new contacts to the queue.If you don't change the Set working queue parameter in the associated contact flow, then Amazon Connect doesn't create new callback contacts.You must update any APIs that use the previous queue's Amazon Resource Name (ARN) with the new callback queue's ARN. For example: the GetMetricData action.For more information, see Set up routing in the Amazon Connect Administrator Guide.Follow"


Question: How do I set up an API Gateway API to handle binary data using a Lambda proxy integration?

I want to return binary data through my Amazon API Gateway REST API (or HTTP API) using an AWS Lambda proxy integration. How do I set that up?

Answer: "I want to return binary data through my Amazon API Gateway REST API (or HTTP API) using an AWS Lambda proxy integration. How do I set that up?ResolutionNote: API Gateway HTTP APIs automatically handle binary data. For API Gateway REST APIs to handle binary data, the backend Lambda function must use the correct output format of a Lambda function for proxy integration.To return binary data through an API Gateway REST API using a Lambda proxy integration1.    In the Lambda console, create a new Lambda function.Note: For an example Python 3 Lambda function, see Return binary media from a Lambda proxy integration.2.    In the API Gateway console, create a new REST API.3.    Create a GET method for the new API by doing the following:In the Resources panel, choose Actions.Choose Create Method. Then, choose GET.In the / - GET - Setup section, for Integration type, choose Lambda Function. Choose the Use Lambda Proxy integration check box.For Lambda Region, choose the region that you created your Lambda function in.For Lambda Function, enter the name of the Lambda function that you created in step 1.Choose Save.In the Add Permission to Lambda Function dialog box that appears, choose OK.4.    In the left navigation pane, in the API section, choose Settings.5.    Under Binary Media Types, choose Add Binary Media Type and add image/png or another file format that you'd like to use, such as application/pdf.6.    Choose Save Changes.7.    Deploy your API to a new stage. For more information, see Setting up a stage using the API Gateway console.Your API is now ready to return binary data through API Gateway using a Lambda proxy integration. For information on how to invoke your API, see Invoking a REST API in Amazon API Gateway.Note: When dealing with binary data, the ;isBase64Encoded property in the output of the Lambda function must be set to true. The body property must also contain the base64 encoded binary media. For more information, see Working with binary media types for REST APIs .To invoke your REST API to return binary data using Postman and cURLImportant: If you use Postman or cURL to invoke your REST API to return binary data, make sure to include the Accept header in the API request. The Accept header value needs to match whatever file format you're using. For example, image/png or application/pdf.For information on how to invoke a REST API using Postman, see Use Postman to call a REST API.For information on how API Gateway encodes payloads, see Content type conversions in API Gateway.Example cURL command to invoke an API Gateway REST API to return binary data$ curl 'https://{restapi_id}.execute-api.{region}.amazonaws.com/{stage_name}/' -H 'Accept: image/png'Note: Replace the following variables before running the example cURL command:For {restapi_id}, enter your API's identifier.For {region}, enter the AWS Region that your API is in.For {stage_name}, enter your API's stage name.For image/png, make sure that you enter the actual image file type that you're using.To invoke your REST API to return binary data using a web browserIf you use a web browser to invoke a REST API to return binary data, make sure that you add text/html as a binary media type to the API.Note: Web browsers automatically send an Accept header with multiple values. By default, the first value is always html/text. Because API Gateway honors the first value only, you must add text/html as a binary media type to the API. Otherwise, you'll get the following error message:"The image "https://{restapi_id}.execute-api.{region}.amazonaws.com/{stage_name}/" cannot be displayed because it contains errors."To add text/html as a binary media type to a REST API, do the following:1.    In the API Gateway console, choose your API.2.    In the left navigation pane, at the bottom of the API section, choose Settings.3.    Under Binary Media Types, choose Add Binary Media Type and add text/html.4.    Chose Save Changes.5.     Deploy your API.For more information, see Content type conversions in API Gateway.Follow"


Question: How do I resolve a HTTP 503 or HTTP 504 error in Amazon OpenSearch Service?

I received an HTTP 503 or HTTP 504 error in Amazon OpenSearch Service. How do I resolve these errors?

Answer: "I received an HTTP 503 or HTTP 504 error in Amazon OpenSearch Service. How do I resolve these errors?ResolutionHTTP 503: This error indicates that one or more cluster nodes don't have enough capacity to handle the request. For more information, see How do I resolve an HTTP 503 Service Unavailable error in Amazon OpenSearch Service?HTTP 504: This error happens when a request fails to complete within the idle timeout period. For more information, see How can I prevent HTTP 504 gateway timeout errors in Amazon OpenSearch Service?Related informationTroubleshooting Amazon OpenSearch ServiceFollow"


Question: How do I lock down API access to specific IP addresses in my Amazon EKS cluster?

I want to lock down API access to specific IP addresses in my Amazon Elastic Kubernetes Service (Amazon EKS) cluster.

Answer: "I want to lock down API access to specific IP addresses in my Amazon Elastic Kubernetes Service (Amazon EKS) cluster.Short descriptionYou can lock down access to two types of Amazon EKS API server access endpoints:Public access endpoints: Access to the API server is open to the public by default. You can lock down access to specific CIDR blocks and IP addresses.Private access endpoints: The API server can be accessed only from within an Amazon Virtual Private Cloud (Amazon VPC). You can further lock down access to specific VPC CIDR blocks through cluster security groups.ResolutionLock down API public access endpointsOpen the Amazon EKS console.In the navigation pane, choose Clusters, and then select your cluster.In the Networking section, choose Update.Expand Advanced Settings.Note: The Advanced Settings options appear only when you activate public access.Enter a CIDR block that you want to allow access from.Note: For example, you can summarize an IP address range from 54.240.193.129 to 54.240.193.190 as 54.240.193.129/26. You can form a single IP address with a /32 notation (for example, 54.240.193.130/32). These CIDR blocks can't include reserved addresses.(Optional) To enter additional blocks, choose Add Source.Choose Update.Keep the following in mind:If you don't specify any CIDR blocks, then the public API server endpoint receives requests from all (0.0.0.0/0) IP addresses.It's a best practice to activate private endpoint access so that worker nodes and AWS Fargate pods (if used) can communicate with the cluster through the private endpoint.Without the private endpoint activated, your public access endpoint CIDR sources must include the egress sources from your Amazon VPC. For example, if you have a worker node in a private subnet that communicates with the internet through a NAT gateway, then you must add the outbound IP address of the NAT gateway as part of a CIDR block that's allowed on your public endpoint.Lock down API private access endpointsOpen the Amazon EKS console.In the navigation pane, choose Clusters, and then select your cluster.In the Networking section, note the name of the cluster security group and any additional security groups.Add ingress rules to any one of the security groups that you noted in step 3.Note: For your ingress rule, set TCP as the protocol, and set 443 as the port and source IP from which you allow access.Related informationModifying cluster endpoint accessFollow"


Question: I set custom object caching on my CloudFront distribution. Why is my distribution using the cache settings of my origin?

"My Amazon CloudFront distribution has a cache behavior with object caching set to Customize, but my distribution still uses the cache settings of my origin. How can I fix this?"

Answer: "My Amazon CloudFront distribution has a cache behavior with object caching set to Customize, but my distribution still uses the cache settings of my origin. How can I fix this?Short descriptionWhen you customize object caching, you configure the Default TTL, Minimum TTL, and Maximum TTL. CloudFront uses these parameters based on whether the origin returns a caching header:If the origin doesn't return a caching header, then the distribution uses the Default TTL.If the origin returns a caching header that's less than the Minimum TTL, then the distribution uses the Minimum TTL.If the origin returns a caching header that's greater than the Maximum TTL, then the distribution uses the Maximum TTL.Note: The response to the client contains the origin's caching headers even when CloudFront caches the response based on Minimum TTL or Maximum TTL. The origin's caching header can be used by any private cache, such as a browser or proxy.If your CloudFront distribution isn't caching based on the custom values that you set on cache behaviors, then check the origin. Verify whether the origin has any conflicting caching headers.ResolutionTo verify whether origin caching headers conflict with your distribution's custom object caching, follow these instructions based on the issues you're seeing:The Minimum TTL and Default TTL are set to 0, but there are still hits from CloudFrontIf there are hits from CloudFront even when a request URI matches a cache behavior path with Minimum TTL and Default TTL set to 0, then check the response from CloudFront. Verify whether the response shows the X-Cache header as "Hit from cloudfront" or "RefreshHit from cloudfront":< HTTP/1.1 200 OK< Content-Type: text/html< Content-Length: 437< Connection: keep-alive< Date: Sat, 03 Feb 2018 19:26:45 GMT< Last-Modified: Sat, 03 Feb 2018 19:25:24 GMT< ETag: "example12345abcdefghijklmno54321"< Cache-Control: max-age=300, Public< Accept-Ranges: bytes< Server: AmazonS3< Age: 14< X-Cache: Hit from cloudfrontIf the X-Cache header is "Hit from cloudfront" or "RefreshHit from cloudfront," then the request was served from the cache of the edge location.Review the rest of the response for the Cache-Control, Expires, and Age headers. The Cache-Control and Expires headers are behavioral caching headers that tell the intermediary (CloudFront) or private (browser) cache how to store a request. The Age header shows how long a response has been cached.If the max-age value for Cache-Control is greater than the value for Age, then the cached response is considered new and is served from the edge location. If the Expires date is still in the future, then the cached response is also considered new. This occurs even if the cache behavior path has Minimum TTL and Default TTL set to 0.The Maximum TTL and Default TTL are greater than 0, but there are misses from CloudFrontIf there are misses from CloudFront even when a request URI matches a cache behavior path with Maximum TTL and Default TTL set to values greater than 0, check the response from CloudFront. Verify whether the response shows the X-Cache header as "Miss from cloudfront":< HTTP/1.1 200 OK< Content-Type: text/html< Content-Length: 437< Connection: keep-alive< Date: Sat, 03 Feb 2018 19:26:45 GMT< Last-Modified: Sat, 03 Feb 2018 19:25:24 GMT< ETag: "example12345abcdefghijklmno54321"< Cache-Control: no-cache, no-store< Accept-Ranges: bytes< Server: AmazonS3< X-Cache: Miss from cloudfrontIf the X-Cache header is "Miss from cloudfront," then the request was retrieved from the origin and wasn't served by the cache.Review the Cache-Control header in the response. If the value for Cache-Control is "no-store," then the header is directing CloudFront to not cache the response. If the value for Cache-Control is "no-cache," then the header is directing CloudFront to verify with the origin before returning a cached response. These directives supersede the Maximum TTL and Default TTL CloudFront settings.Note: Responses that aren't from the cache won't have an Age header.CloudFront is caching error responsesBy default, CloudFront forwards error responses from the origin to the client. Additionally, CloudFront caches the origin's error response for 10 seconds by default.If the error response from the origin contains a Cache-Control header, CloudFront caches the error with the relevant TTL instead of the default 5 minutes. CloudFront doesn't cache its own error responses, unless specified otherwise in a custom error response.To determine whether the error response is from the origin or CloudFront, check the Server header. To determine whether the error is a cached response, check the Age header—a cached response includes an Age header.The following example is an error from an Amazon Simple Storage Service (Amazon S3) origin that's a cached response:< HTTP/1.1 403 Forbidden< Content-Type: application/xml< Transfer-Encoding: chunked< Connection: keep-alive< Date: Sat, 03 Feb 2018 21:07:51 GMT< Server: AmazonS3< Age: 12< X-Cache: Error from cloudfrontThe following example is an error from CloudFront that isn't a cached response:< HTTP/1.1 403 Forbidden< Server: CloudFront< Date: Sat, 03 Feb 2018 21:14:53 GMT< Content-Type: text/xml< Content-Length: 146< Connection: keep-alive< X-Cache: Error from cloudfrontAfter you identify the conflicting caching headers, update the originAfter you determine which caching headers are superseding your distribution's custom object caching, follow these steps:Identify where in the web server configuration the headers are applied.Remove the lines where the headers are applied.Restart the server.Test your origin directly to be sure that the caching headers are no longer returned in the response.Run an invalidation on your entire CloudFront distribution to apply the change.Related informationCaching content based on request headersFollow"


Question: How can I use a client certificate issued by a third party when configuring mutual TLS authentication for API Gateway APIs?

I want to use a client certificate issued by a third party when configuring mutual Transport Layer Security (TLS) authentication for Amazon API Gateway APIs.

Answer: "I want to use a client certificate issued by a third party when configuring mutual Transport Layer Security (TLS) authentication for Amazon API Gateway APIs.ResolutionTo use a third-party signed client certificate for API Gateway with TLS authentication, follow these steps:Create a truststore to use the third-party signed certificate.Create a custom domain name and API mapping for your API Gateway API.Create a DNS record to map the custom domain name to API Gateway.Disable the default endpoint.Test the API.Note: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.Mutual TLS isn't supported for private APIs.Create a truststore to use the third-party signed certificate1.    Generate a RootCA. The RootCA is used to issue the client certificate.openssl genrsa -out RootCA.key 4096    openssl req -new -x509 -days 3650 -key RootCA.key -out RootCA.pem2.    Fill in the required fields, and enter domain name.3.    Create a client certificate private key, certificate signing request (CSR), and client certificate.openssl genrsa -out my_client.key 2048    openssl req -new -key my_client.key -out my_client.csr4.    Sign the client certificate using the CA that you created previously.openssl x509 -req -in my_client.csr -CA RootCA.pem -CAkey RootCA.key -set_serial 01 -out my_client.pem -days 3650 -sha2565.    Create an Amazon Simple Storage Service (Amazon S3) bucket to store the truststore.pem file.6.    Upload the RootCA.pem to the Amazon S3 bucket truststore.7.    (Optional) Create a certificate chain file from the intermediate CA certificate to Root CA.Cat Intermediate.pem ca.pem >ca-chain.pem.For more information, see Configuring your truststore.Create a custom domain name and API mapping for your API Gateway APINote: Only certificates with a key size of 2048 bits are visible with API Gateway. The certificate size can't exceed 2048 bits.1.    Open the API Gateway console, and then choose Custom domain names.2.    For Domain names, enter your domain name, and then choose Create.3.    For Domain name, enter your domain name.4.    For Minimum TLS version, choose TLS 1.2.5.    Enable Mutual TLS authentication.6.    For Truststore URI, enter the Amazon S3 URI that you created earlier.7.    For Endpoint configuration, choose Regional.8.    For Certificate type, choose your certificate type, and then choose Create domain name.9.    Choose your custom domain name, and then choose Configure API mappings.10.    Choose Add new mapping.11.    Choose the API, Stage, and Path for the mapping, and then choose Save.For more information, see How can I set up a custom domain name for my API Gateway API?Create a DNS record to map the custom domain name to API GatewayCreate a DNS record to point the custom domain name to the API Gateway Regional domain name. This allows the traffic that's bound to the custom domain name to be routed to the API's Regional hostname. The DNS record can be the CNAME or "A Alias" type.For more information, see Configuring Route 53 to route traffic to an API Gateway endpoint.Disable the default endpointBy default, clients can invoke APIs using the execute-api endpoint that API Gateway generates for your API. Disable the default execute-api endpoint so that clients can access your API using only a custom domain name.For HTTP APIs, see Disabling the default endpoint for an HTTP API.For REST APIs, see Disabling the default endpoint for a REST API.Test the APITest the API with the --key and --cert parameters to send the client certificate as part of the request.$ curl -v https://{YourCustomDomainName}/{resource} --key my_client.key --cert my_client.pemNote: The private key my_client.key and the client certificate my_client.pem must be included for a successful request.Related informationHow can I troubleshoot certificate chain and self-signed certificate issues for Amazon API Gateway with custom domains and mutual TLS enabled?Introducing mutual TLS authentication for Amazon API GatewayHow do I troubleshoot HTTP 403 Forbidden errors from an API Gateway custom domain name that requires mutual TLS?Follow"


Question: Why can't my server receive email after I created an MX record for my SMTP server in Route 53?

I created a mail exchanger (MX) record for my Simple Mail Transfer Protocol (SMTP) server in Amazon Route 53. Now my server can't receive email.

Answer: "I created a mail exchanger (MX) record for my Simple Mail Transfer Protocol (SMTP) server in Amazon Route 53. Now my server can't receive email.Short descriptionIf you don't properly configure the public hosted zone that for the Route 53 DNS service, then clients can't connect to your SMTP server. To properly configure your public hosted zone, verify the following settings:The public hosted zone is populated with the appropriate resource record sets.Your non-AWS domain name registrar points to the name servers in your Route 53 public hosted zone.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.Confirm that you're using the appropriate resource record setsConfirm that you created the appropriate resource record sets for your SMTP server. For more information, see Values that you specify when you create or edit Amazon Route 53 resource records. At minimum, the public hosted zone must contain an MX record for your SMTP server. For more information, see Values specific for simple records.Confirm that your non-AWS domain name registrar points to the name servers in your Route 53 public hosted zoneYou can use Route 53 for DNS services and another domain name registrar for domain registration. In this case, your domain name registrar must reference the name servers in your Route 53 public hosted zone. To do this, query an internet-based whois utility to take the following steps:Find the registrar for your domain name. Enter your domain name in the query field, select the Domain option, and then choose Submit. The query results include the domain name registrar and the authoritative name servers for the domain name.Note: The query results might return a list of name servers other than the name servers that are associated with your Route 53 public hosted zone. In this case, the DNS queries for your SMTP server aren't sent to Route 53. To update the list of name servers that are associated with your domain name, contact your domain name registrar.Find contact information for your domain registrar. Enter the name of the registrar in the query field, select the Registrar option, and then choose Submit. Use this information to contact your domain registrar. Ask your domain registrar to update the list of name servers, so your domain name can reference them in its public hosted zone.Verify that the DNS service that you're transferring from doesn't delete resource record sets before the time to live (TTL) on the registrar's name servers expires. Route 53 DNS services don't respond to DNS queries for a domain name until the TTL period for the domain name server records elapses. For more information, see I changed DNS settings, but they haven't taken effect.Check for DNS MX record set issues1.    To confirm that an MX record for the domain exists, run the following commands:Linux or macOSdig DOMAIN_NAME MXThis returns an output similar to the following dig example:$ dig amazon.com MX; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.2 <<>> amazon.com MX;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61726;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096;; QUESTION SECTION:;amazon.com.                    IN      MX;; ANSWER SECTION:amazon.com.             300     IN      MX      5 amazon-smtp.amazon.com.;; Query time: 1 msec;; SERVER: 10.10.0.2#53(10.10.0.2);; WHEN: Wed Apr 14 06:21:43 UTC 2021;; MSG SIZE  rcvd: 67Windowsnslookup -type=MX DOMAIN_NAMEThis returns an output similar to the following nslookup example:$ nslookup -type=MX amazon.comServer:         10.10.0.2Address:        10.10.0.2#53Non-authoritative answer:amazon.com      mail exchanger = 5 amazon-smtp.amazon.com.2.    To confirm that you can resolve the MX record hostname, run the following commands:Linux or macOSdig MX_RECORDThis returns an output similar to the following dig example:$ dig amazon-smtp.amazon.com; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.2 <<>> amazon-smtp.amazon.com;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64180;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096;; QUESTION SECTION:;amazon-smtp.amazon.com.                IN      A;; ANSWER SECTION:amazon-smtp.amazon.com. 27      IN      A       52.94.124.7;; Query time: 1 msec;; SERVER: 10.10.0.2#53(10.10.0.2);; WHEN: Wed Apr 14 06:41:18 UTC 2021;; MSG SIZE  rcvd: 67Windowsnslookup MX_RECORDThis returns an output similar to the following nslookup example:$ nslookup amazon-smtp.amazon.comServer:         10.10.0.2Address:        10.10.0.2#53Non-authoritative answer:Name:   amazon-smtp.amazon.comAddress: 52.119.213.154Note: Some DNS providers require that you prepend an at symbol (@) to an MX record set name. Or, providers might require you to create an MX record set with the name "@" when creating an MX record set for a root domain. However, don't prepend Route 53 MX record set names with the "@" or any other symbol. To create an MX record set for a root domain in Route 53, leave the record set name blank. Then, provide appropriate values for the remaining fields of the Route 53 MX record set.Test sending and receiving emailConnect to the mail server and test your ability to send and receive email using SMTP commands.1.    Enter the following command, and then press Enter. Be sure to replace the placeholder values with your mail server name or IP address and the port number:telnet MAIL_SERVER_NAME_OR_IP MAIL_SERVER_PORT_NUMBERNote: If you make a typographical error in this command, press Enter. Pressing Backspace or Delete doesn't work in this case. After you press Enter, retry the command. In some cases, you might need to close the telnet session and reconnect.2.    Enter the following command, and then press Enter. Be sure to replace the placeholder value with your mail server domain name:EHLO YOUR_MAIL_SERVER_FULLY_QUALIFIED_DOMAIN_NAME3.    Enter the following command, and then press Enter. Be sure to replace the placeholder value with your email address:mail from: your_name@yourdomainnameThe server responds with 250 OK.4.    Enter the following command, and then press Enter. Be sure to replace the placeholder value with the recipient's email address:rcpt to: recipient@yourdomainnameNote: The sender and recipient can have the same email address.The server responds with 250 Accepted.Important: If the server can verify information such as the sender and recipient, then the message is confirmed as accepted.5.    Enter the following command, and then press Enter:data6.    Enter the following command, and then press Enter:Subject: SPECIFY_SUBJECT_HERE7.    Enter the following command, and then press Enter:SPECIFY_MESSAGE_HERE8.    Enter the following command, and then press Enter:.The server accepts the message for delivery and responds with 250 OK to indicate that it sent the email.9.    If you confirm that the MX record is configured correctly but your SMTP server still can't receive email, contact your email service provider.Follow"


Question: Why can't I connect to a website that is hosted on my EC2 instance?

I can't connect to a public website that is hosted on my Amazon Elastic Compute Cloud (Amazon EC2) instance. How do I resolve this?

Answer: "I can't connect to a public website that is hosted on my Amazon Elastic Compute Cloud (Amazon EC2) instance. How do I resolve this?Short descriptionWebsites running on an EC2 instance might become unreachable for multiple reasons. To resolve this issue, confirm that the configuration settings on your EC2 instance are correct. For example, if your instance isn't booting correctly or doesn't have the right DNS configurations, you can't connect to any website hosted on that instance.Use the steps in this article to check the configuration settings of your EC2 instance and find the root cause of this issue.ResolutionNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent version of the AWS CLI.Use the EC2 Serial Console for Linux to troubleshoot Nitro-based instance typesIf you turned on EC2 Serial Console for Linux, you can use it to troubleshoot supported Nitro-based instance types. You can access the serial console using the serial console or the AWS CLI. You don't need a working connection to connect to your instance when you use the EC2 Serial console.Before you use the serial console to troubleshoot, follow these steps:Grant access to the serial console at the account levelCreate AWS Identity and Access Management (IAM) policies granting access to your IAM usersCheck that your instance includes at least on password-based userCheck that the instance is running and passing both status checksMake sure that the instance is listed as running in the Amazon EC2 console. If your instance isn't running or you have another status check issue, follow the steps in Why is my EC2 Linux instance unreachable and failing one or both of its status checks?Check that the instance boots correctlyCheck the instance's system logs for boot errors.If you see a kernel panic error, see I'm receiving a "Kernel panic" error after I've upgraded the kernel or tried to reboot my EC2 Linux instance. How can I fix this?For other operating system errors, see My EC2 Linux instance failed the instance status check due to operating system issues. How do I troubleshoot this?Check the instance's security group and network ACL configurationMake sure that the instance's associated security group and network ACL allow traffic on port 80 and 443 .Make sure that the route table in the instance's subnet has a default route to an internet gateway.Check that the instance has the correct DNS configurationIf your website uses Route 53 DNS service, check that you've configured the DNS records correctly.Make sure that the instance has an Elastic IP address assigned to it. If you stop and start your instance, the Elastic IP address is still associated with the instance.Make sure to map the public IP address or Elastic IP address to an A-record.Check that the web server is running and that there are no OS-level firewalls blocking access to portsNetwork ports are the communication endpoints that various services send requests to. These requests include users' website connection requests. Web servers listen on port 80 for HTTP traffic and use port 443 for traffic encrypted with TLS/SSL. If the web server isn't running or firewalls block these ports, then users can't connect to your website.To check if the website is running locally, run this command from within the EC2 instance hosting website:curl https://localhost-or-curl http://localhost:4431.    Remotely connect to the instance through SSH.2.    Check the web server status.For RHEL or CentOS systems, use the command systemctl status httpd to check the web server's status. The command returns information that the web server is inactive:$ sudo systemctl status httpdhttpd.service - The Apache HTTP ServerLoaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)Active: inactive (dead)For Debian or Ubuntu systems, the use command systemctl status httpd to check the web server's status. The web server must be listening on port 80 or 443. The command returns information that the web server is inactive:$ sudo systemctl status apache2apache2.service - The Apache HTTP ServerLoaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)Active: inactive (dead)3.    To restart the web server, run this command:For REHL or CentOS systems:$ sudo systemctl restart httpdFor Debian or Ubuntu systems, run this command:$ sudo systemctl restart apache24.    Verify that the web server is now running:For REHL or CentOS systems, run this command:$ sudo systemctl status httpdhttpd.service - The Apache HTTP ServerLoaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)Active: active (running) since Thu 2020-11-19 14:40:15 UTC; 42s agoFor Debian or Ubuntu systems, run this command:$ sudo systemctl status apache2apache2.service - The Apache HTTP ServerLoaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)Active: active (running)Note: For older Linux systems running SystemV, run this command to check the web server status.For Debian or Ubuntu systems, you must replace httpd with apache2:$ sudo service httpd statushttpd is stoppedTo restart a stopped web server on SystemV, run this command:$ sudo service httpd restartStopping httpd:                                            [FAILED]Starting httpd:                                            [  OK  ]5.    Run this command to confirm that the web server is listening on port 80 or 443 for incoming connection requests from users:For REHL or CentOS systems, run this command:$ sudo netstat -tulpn | grep httpdtcp        0      0 :::80                       :::*                        LISTEN      2961/httpdFor Debian or Ubuntu systems, run this command:$ sudo netstat -tulpn | grep apache2tcp6       0      0 :::80                   :::*                    LISTEN      2741/apache26.    Verify the status of OS-level firewalls. If you find an active firewall, make sure that it allows requests on ports 80 and 443.Note: If there are multiple interfaces running, confirm that the web server is listening on all IPs by running this command:cat /etc/httpd/conf/httpd.conf  | grep ListenThese are examples of successful outputs:Listen *:80-or-Listen *:443Amazon Linux, CentOS, and RHEL:1.    Run this command to check that the iptables rules block incoming requests on ports 80 and 443:$ sudo iptables -nvLChain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target     prot opt in     out     source               destination         Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target     prot opt in     out     source               destination         Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target     prot opt in     out     source               destination2.    Run this command to allow port 80 to accept incoming HTTP connection requests:$ sudo iptables -A INPUT -p tcp --dport 80 --syn -m conntrack --ctstate NEW -j ACCEPT3.    Run this command to allow port 443 to accept incoming HTTPS connection requests:$ sudo iptables -A INPUT -p tcp --dport 443 --syn -m conntrack --ctstate NEW -j ACCEPTAmazon Linux 2 and RHEL 7 and above:1.    Run this command to check that firewalld is running:$ sudo firewall-cmd --staterunning2.    If firewalld is running, then run these commands to configure it to allow connections on ports 80 and 443. The last command in this example reloads the service so that the new rules take effect:$ sudo firewall-cmd --add-service=http --permanentsuccess$ sudo firewall-cmd --add-service=https --permanentsuccess$ sudo firewall-cmd --reloadsuccessDebian and Ubuntu servers:1.    Run this command to check for a UFW firewall:$ sudo ufw status verboseStatus: active2.    If UFW is running, use this command to allowing incoming connection requests on ports 80 and port 443:$ sudo ufw allow in 80/tcpRule addedRule added (v6)$ sudo ufw allow 443/tcpRule addedRule added (v6)Check your web server access error logs for issues. Web server logs are located at /var/log. This location might change, depending on your server configuration. These are default web server log locations:Amazon Linux and RHEL: /var/log/httpdDebian and Ubuntu: /var/log/apache2Related informationHow do I troubleshoot slow connections to a website hosted on my EC2 instance?Follow"


Question: How do I resolve the "Did not have IAM permissions to process tags on AWS::EC2::Instance resource" error when I create an AWS::EC2::Instance resource in CloudFormation?

I receive the "Did not have IAM permissions to process tags on AWS::EC2::Instance resource" error when I try to create an AWS::EC2::Instance resource in AWS CloudFormation.

Answer: "I receive the "Did not have IAM permissions to process tags on AWS::EC2::Instance resource" error when I try to create an AWS::EC2::Instance resource in AWS CloudFormation.Short descriptionYou receive this error when you create an AWS::EC2::Instance resource and the following is true:You specify a value for the Tags property in your CloudFormation template.The AWS Identity and Access Management (IAM) user, IAM role, or CloudFormation service role doesn't have the required ec2:CreateTags permissions.When this error occurs, the custom tags specified using the Tags property aren't applied to the EC2 instance even though the resource is marked CREATE_COMPLETE.Note: 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.Resolution1.    Confirm that the IAM user, IAM role, or CloudFormation service role that creates the CloudFormation stack has permissions to perform ec2:CreateTags and ec2:DeleteTags on your affected EC2 instances.2.    Use the CloudFormation console or AWS CLI to comment out the Tags property of the AWS::EC2::Instance resource in your affected CloudFormation template. Then, update your stack.Using the CloudFormation console:In your CloudFormation template, comment out the Tags property, and then update your stack. For example:Resources:  MyEC2Instance:     Type: AWS::EC2::Instance    Properties: #      Tags: #      - Key: key1#        Value: value1#      - Key: key2#        Value: value2Using the AWS CLI:Run the update-stack command:aws cloudformation update-stack --region YOUR_REGION --template-body file://YOUR_TEMPLATE_FILE_TAGS_COMMENTED —stack-name YOUR_STACK_NAMENote: Replace YOUR_REGION, YOUR_TEMPLATE_FILE_TAGS_COMMENTED, and YOUR_STACK_NAME with your values.3.    Use the CloudFormation console or AWS CLI to uncomment the Tags property of the AWS::EC2::Instance resource in your affected CloudFormation template. Then, update your stack again.Using the CloudFormation console:In your CloudFormation template, remove the comments from the Tags property, and then update your stack. For example:Resources:  MyEC2Instance:     Type: AWS::EC2::Instance    Properties:       Tags:       - Key: key1        Value: value1      - Key: key2        Value: value2Using the AWS CLI:Run the update-stack command:aws cloudformation update-stack --region YOUR_REGION --template-body file://YOUR_TEMPLATE_FILE_TAGS_UNCOMMENTED —stack-name YOUR_STACK_NAMENote: Replace YOUR_REGION, YOUR_TEMPLATE_FILE_TAGS_UNCOMMENTED, and YOUR_STACK_NAME with your values.4.    Use the EC2 console or AWS CLI to check if your tags are correctly applied to your Amazon Elastic Compute Cloud (Amazon EC2) instances.Using the Amazon EC2 console:1.    Open the Amazon EC2 console.2.    From the Instances section of the navigation pane, choose Instances.3.    Select the instance that was created through CloudFormation.4.    Choose the Tags tab, and then check if the custom tags specified in your CloudFormation template are populated in the table.Using the AWS CLI:Run the describe-tags command:aws ec2 describe-tags —filters "Name=resource-id,Values=YOUR_INSTANCE_ID"Note: Replace YOUR_INSTANCE_ID with the instance ID of the EC2 instance from your stack.Follow"


Question: I received a notice stating that Amazon EC2 detected degradation of the underlying hardware hosting my EC2 instance. What do I need to do?

I received a notice stating that there is degradation of the underlying hardware hosting my Amazon Elastic Compute Cloud (Amazon EC2) instance. What do I need to do?

Answer: "I received a notice stating that there is degradation of the underlying hardware hosting my Amazon Elastic Compute Cloud (Amazon EC2) instance. What do I need to do?Short descriptionIf a hardware malfunction occurs, then Amazon EC2 tags the specific hardware as faulty. Any instances that are running on the hypervisor of the faulty hardware are moved to healthy hardware. During the transition to new hardware, the Amazon EBS-backed instances are stopped and instance store-backed instances are terminated. Amazon EC2 sends a notification through email and to your Personal Health Dashboard informing you of the hardware degradation and of the upcoming instance stop or termination.Note: Instances launched from an Amazon EC2 Auto Scaling group might terminate as soon as the instance’s system status check fails. If this occurs, the Amazon EC2 Auto Scaling group launches a new replacement instance for the terminated instance. By the time you receive a hardware degradation notification from Amazon EC2, you can't see the original instance in your dashboard. You can review the AWS CloudTrail log file for that instance to view the termination. For more information on how to check an instance from CloudTrail logs, see How do I search CloudTrail logs for API calls to run, stop, start, and terminate EC2 instances?ResolutionIf you receive a hardware degraded notice, you can manually stop and start the instance using the Amazon EC2 console or AWS Command Line Interface (AWS CLI). The stop removes the instance from the faulty hardware. Starting the instance launches it on healthy hardware.Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.Stop and start the instanceNote: A stop and start isn't equivalent to a reboot. A start is required to migrate the instance to healthy hardware.Important:This procedure requires a stop and start of your EC2 instance. Instance store data is lost when an instance is stopped and then started again. If your instance is instance store-backed or has instance store volumes containing data, the data is lost when the instance is stopped. For more information, see Determining the root device type of your instance.If your instance is part of an Amazon EC2 Auto Scaling group or if your instance is launched by services that use AWS Auto Scaling, such as Amazon EMR, AWS CloudFormation, AWS Elastic Beanstalk, and so on, then stopping the instance could terminate the instance. Instance termination in this scenario depends on the instance scale-in protection settings for your Auto Scaling group. If your instance is part of an Auto Scaling group, temporarily remove the instance from the Auto Scaling group before starting the resolution steps.Stopping and starting the instance changes the public IP address of your instance. It's a best practice to use an Elastic IP address instead of a public IP address when routing external traffic to your instance.To stop and start the instance, complete the following steps:Open the Amazon EC2 console and then select the instance.Select Actions, Instance State, Stop.Select Yes, Stop.Note: If your instance is stuck in the stopping state, you might want to force the instance to stop. For more information on stopping an instance stuck in the stopping state, see Troubleshooting stopping your instance.Select the instance again.Select Actions, Instance State, Start.Select Yes, Start.Note: The hardware degradation notification remains in your Personal Health Dashboard with a status of Completed until the stop or terminate date listed in the notification.(Optional) Set up instance recovery for your instancesYou can create an Amazon CloudWatch alarm that automatically recovers instances experiencing underlying hardware degradation. For information on how to set up the CloudWatch alarm, see Recover your instance.Follow"


Question: How does my SageMaker container access Amazon S3 data and push logs to CloudWatch when I turn on network isolation?

I turned on network isolation for my Amazon SageMaker container. I want to know how the container accesses the Amazon Simple Storage Service (Amazon S3) data and pushes the logs to Amazon CloudWatch.

Answer: "I turned on network isolation for my Amazon SageMaker container. I want to know how the container accesses the Amazon Simple Storage Service (Amazon S3) data and pushes the logs to Amazon CloudWatch.ResolutionWhen you turn on network isolation, SageMaker accesses Amazon S3 and CloudWatch in isolation to the training or inference containers. If you don't specify an Amazon Virtual Private Cloud (Amazon VPC), then data access and logging happens on the server side. In this case, the container can't access the network.When you specify VpcConfig in your training, processing, or model configuration, SageMaker creates two elastic network interfaces in the specified Amazon VPC. All the traffic is routed through these two elastic network interfaces in the specified VPC. One elastic network interface is for the algorithm container, and the other is for Amazon S3 and logging access. If you specify an Amazon VPC in VpcConfig, then the network isolation setting doesn't create the elastic network interface for the algorithm container. This blocks the container from all outbound networking calls. The other elastic network interface remains, and you can use it for Amazon S3 and logging access.In both cases, the internal SageMaker processes that are running on the nodes download the data. Then, the input channels that are specified in the job definition make this data available to the algorithm container. Also, the internal processes that are running on the node make the logs and metrics available to CloudWatch. These nodes connect to CloudWatch through the VPC that's in VpcConfig.Whether or not you specify VpcConfig, the container doesn't have access to any AWS credentials to make API calls to AWS services.Related informationNetwork isolationFollow"