VishaalY/solutions-architect-hf-dataset huggingface dataset:
Question: How do I empty an Amazon S3 bucket using a lifecycle configuration rule?

I have an Amazon Simple Storage Service (Amazon S3) bucket that stores millions of objects. I want to empty the bucket using a lifestyle configuration rule so that I won't be charged for storage anymore.

ResolutionFollow these steps to create a lifecycle configuration rule that expires current versions of objects and permanently delete previous versions of objects:1.    Open the Amazon S3 console.2.    From the list of buckets, choose the bucket that you want to empty.3.    Choose the Management tab.4.    Choose Create lifecycle rule.5.    For Lifecycle rule name, enter a rule name.6.    For Choose a rule scope, select This rule applies to all objects in the bucket.7.    Select I acknowledge that this rule will apply to all objects in the bucket.8.    For Lifecycle rule actions, select the following to create a lifecycle rule:Expire current versions of objectsPermanently delete previous versions of objectsDelete expired delete markers or incomplete multipart uploads9.    In the Expire current versions of objects field, enter "1" in the Days after object creation field.10.    In the Permanently delete previous versions of objects field, enter "1" in the Number of days after objects become noncurrent field.11.    Leave the Number of newer versions to retain field empty to delete all versions.12.    Select Delete incomplete multipart uploads and enter "1" for the Number of days field.13.    Choose Create rule.14.    Create a second lifecycle rule by repeating steps 4-7.15.    Then, select the following: Delete expired delete markers or incomplete multipart uploads16.    Select Delete expired object delete markers.17.    Choose Create rule.Amazon S3 runs lifecycle rules once every day. After the first time that Amazon S3 runs the rules, all objects that are eligible for expiration are marked for deletion. You're no longer charged for objects that are marked for deletion. However, rules might take a few days to run before the bucket is empty because expiring object versions and cleaning up delete markers are asynchronous steps. For more information about this asynchronous object removal in Amazon S3, see Expiring objects.

Related informationRemoving expired object delete markersManaging your storage lifecycleHow do I delete Amazon S3 objects and buckets?Deleting a bucket
Question: Can I modify the terms of my Amazon EC2 Reserved Instance?

I purchased an Amazon Elastic Compute Cloud (Amazon EC2) Reserved Instance, but I want to modify the attributes of my Reserved Instance contract.

ResolutionFirst, check the conditions that are listed at Requirements and restrictions for modification. If your Reserved Instance meets the conditions, then you can request to modify the following attributes:Availability ZoneScopeInstance sizeNetwork platformIf your modification request meets the guidelines and you’re ready to request a modification, then see Submitting modification requests.If you purchased a Convertible Reserved Instance, then consider exchanging the Reserved Instance for another Convertible Reserved Instance. For more information, see Exchange Convertible Reserved Instances.

Related informationAmazon EC2 FAQsHow to purchase Amazon EC2 Reserved InstancesWhat are the differences between Standard and Convertible Reserved Instances?
Question: How do I set up a trusted IP address list for GuardDuty?

I want to set up a trusted IP address list for Amazon GuardDuty.

Short descriptionYou can configure GuardDuty to use your own custom trusted IP list. Use this list to configure your allowed IP addresses for secure communication with your AWS infrastructure and applications. For more information, see Working with trusted IP lists and threat lists.

ResolutionCreate a trusted IP listReview the accepted format for trusted IP list files. Then, follow the instructions to upload the file to an Amazon Simple Storage Service (Amazon S3) bucket.Note: The trusted IP list file must be in TXT, STIX, OTX_CSV, ALIEN_VAULT, PROOF_POINT, or FIRE_EYE format. The trusted IP list doesn't support IPv6 addresses. You can have a maximum number of 2000 IP addresses and CIDR for each trusted IP list. You can have only one trusted IP list per Detector resource. For more information, see Quotas for Amazon GuardDuty.Check IAM identity permissionsBe sure that your AWS Identity and Access Management (IAM) identity has permissions with trusted IP lists and GuardDuty:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "VisualEditor0",      "Effect": "Allow",      "Action": [        "guardduty:*IPSet*",        "guardduty:List*",        "guardduty:Get*"      ],      "Resource": "*"    }  ]}Be sure that your IAM identity has permissions for PutRolePolicy and DeleteRolePolicy for the GuardDuty service linked role AWSServiceRoleForAmazonGuardDuty.{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "VisualEditor0",      "Effect": "Allow",      "Action": [        "iam:DeleteRolePolicy",        "iam:PutRolePolicy"      ],      "Resource": "arn:aws:iam::123456789123:role/aws-service-role/guardduty.amazonaws.com/AWSServiceRoleForAmazonGuardDuty"    }  ]}For more information, see Editing IAM policies.Add and activate a trusted IP list in GuardDutyOpen the GuardDuty console.In the navigation pane, choose Lists.Choose Add a trusted IP list.For List name, enter a name that is meaningful to you.For Location, enter the location for your S3 bucket. For example, https://s3.amazonaws.com/bucket-name/file.txt.Choose the Format dropdown menu, and then choose your list's file type.Select the I agree check box, and then choose Add list.In Trusted IP lists, choose Active for your trusted IP list name.Note: It might take up to 5 minutes for the list to activate.If you change a trusted IP list in GuardDuty, you must update and then reactivate the list. For instructions, see To update trusted IP lists and threat lists.

Related informationHow to use Amazon GuardDuty and AWS Web Application Firewall to automatically block suspicious hostsWhy did GuardDuty send me alert findings for a trusted IP list address?
Question: How can I require MFA authentication for IAM users that use the AWS CLI?

I created a multi-factor authentication (MFA) condition policy to restrict access to AWS services for AWS Identity and Access Management (IAM) users. The policy works with the AWS Management Console, but not with the AWS Command Line Interface (AWS CLI). How can I use MFA with the AWS CLI?Short descriptionThe following example IAM policy requires IAM users to use MFA to access specific AWS services:{  "Sid": "BlockMostAccessUnlessSignedInWithMFA",  "Effect": "Deny",  "NotAction": [    "iam:CreateVirtualMFADevice",    "iam:DeleteVirtualMFADevice",    "iam:ListVirtualMFADevices",    "iam:EnableMFADevice",    "iam:ResyncMFADevice",    "iam:ListAccountAliases",    "iam:ListUsers",    "iam:ListSSHPublicKeys",    "iam:ListAccessKeys",    "iam:ListServiceSpecificCredentials",    "iam:ListMFADevices",    "iam:GetAccountSummary",    "sts:GetSessionToken"  ],  "Resource": "*",  "Condition": {    "Bool": {      "aws:MultiFactorAuthPresent": "false",      "aws:ViaAWSService": "false"    }  }}IAM users with the AWS Management Console are prompted to enter MFA authentication credentials and can then access AWS services. However, IAM users with the AWS CLI aren't prompted to enter MFA authentication credentials and can access AWS services.

ResolutionNote: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.The MultiFactorAuthPresent key doesn't exist in requests made using long-term credentials. With the Boolean condition operator, if the key in the policy isn't present, then the values don't match. The MultiFactorAuthPresent key doesn't deny access to requests made using long-term credentials.IAM users using the AWS Management Console generate temporary credentials and allow access only if MFA is used.The Boolean condition lets you restrict access with a key value set to true or false. You can add the IfExists condition operator to check if the MultiFactorAuthPresent key is present in the request. If the MultiFactorAuthPresent key isn't present, IfExists evaluates the condition element as true similar to the following:"Effect" : "Deny","Condition" : { "BoolIfExists" : { "aws:MultiFactorAuthPresent" : "false", "aws:ViaAWSService":"false"} }Note: IAM users using the AWS CLI with long-term credentials are denied access and must use MFA to authenticate. Therefore, be sure to use an MFA token to authenticate your CLI session.

Related informationUsing multi-factor authenticationAssumeRoleEnabling and managing virtual MFA devices (AWS CLI or AWS API)
Question: How can I send custom HTTP responses for specific URLs from an Application Load Balancer?

I want to forward custom HTTP responses and drop client requests for specific URLs. How can I send custom HTTP responses for specific URLs from an Application Load Balancer?ResolutionYou can use fixed-response actions to drop client requests and return a custom HTTP response. You can use this action to return a 2XX, 4XX, or 5XX response code and an optional message.To add a rule with a fixed-response action on your Application Load Balancer's listener:Open the Amazon Elastic Compute Cloud (Amazon EC2) console.On the navigation pane, from LOAD BALANCING, choose Load Balancers.Select your load balancer and choose the Listenerstab.Choose View/edit rules.Choose Add rules(the plus sign) in the menu bar. This action allows you to add Insert Ruleicons at every location where you can insert a rule in the priority order.Define the rule as follows:Choose Insert Rule.(Optional) To configure host-based routing, choose Add condition, Host is. Enter the hostname (for example, *.example.com), and then choose the check mark.(Optional) To configure path-based routing, choose Add condition, Path is. Enter the path pattern (for example, /img/*), and then choose the check mark.To add a fixed-response action, choose Add action, Return fixed response. Enter a response code and optional response body, and then choose the check mark.(Optional) To change the order of the rule, use the arrows. The default rule always has the last priority.Choose Save.Related InformationListener Rules
Question: How do I migrate an EC2-Classic instance to a VPC in same Region of same account?

I have multiple Amazon Elastic Compute Cloud (Amazon EC2) instances in EC2-Classic. I want to migrate the EC2-Classic instances to a virtual private cloud (VPC) before EC2-Classic is no longer available.

ResolutionYou can use the AWSSupport-MigrateEC2ClassicToVPC Automation document to migrate your EC2-Classic instances to a VPC in the same Region of the same AWS account. The runbook supports only EC2-Classic instances with a virtualization type of HVM and a root volume type of EBS.Before using this Automation document, verify the service quotas for the following resources in the VPC:Elastic IP addressesEC2 instancesSecurity groupsIf necessary, increase the quotas before running the Automation. For more information about how to request a quota increase, see AWS service quotas.Note: AWS is retiring EC2-Classic. For more information, see EC2-Classic Network is retiring - Here's how to prepare.Migrate an EC2-Classic instance to a VPCOpen the AWS Systems Manager console, and then choose Automation from the navigation pane.Choose Execute automation.On the Owned by Amazon tab, in the Automation document search box, enter MigrateEC2Classic.Select the radio button for the AWSSupport-MigrateEC2ClassicToVPC document, and then choose Next.Under Input parameters, for InstanceId, enter your source EC2-Classic instance ID.For AutomationAssumeRole and TargetInstanceType, choose your required parameters. By default, TargetInstanceType is set to t2.xlarge.Note:: For more information about the AWS Identity and Access Management (IAM) permissions that are required for AutomationAssumeRole to successfully run the Automation, see AWSSupport-MigrateEC2ClassicToVPC.(Optional) For DestinationSubnetId and DestinationSecurityGroupId, enter your subnet ID and VPC security group ID.Note:: If these fields are left blank, then the Automation selects a random subnet in the default VPC. Security groups that are attached to the source instance are copied to the VPC and used to launch the target instance.For MigrationType, select Test or CutOver.If you select CutOver for MigrationType, then set the following parameters:SNSNotificationARNForApproval: Enter the ARN of the SNS topic used to send Approval notifications to stop the source instance.ApproverIAM: Enter the ARN of the IAM users or roles that can approve or reject the action to stop the source instance.Choose Execute.

Related informationMigrate from EC2-Classic to a VPC
Question: How do I resolve the "HIVE_PATH_ALREADY_EXISTS" exception when I run a CTAS query in Amazon Athena?

When I run a CREATE TABLE AS SELECT (CTAS) query in Amazon Athena, I get the exception: "HIVE_PATH_ALREADY_EXISTS: Target directory for table".

ResolutionIf you use the external_location parameter in the CTAS query, then be sure to specify an Amazon Simple Storage Service (Amazon S3) location that's empty. The Amazon S3 location that you use to store the CTAS query results must have no data. When you run your CTAS query, the query checks that the path location or prefix in the Amazon S3 bucket has no data. If the Amazon S3 location already has data, the query doesn't overwrite the data.To use the Amazon S3 location that has data in your CTAS query, delete the data in the key prefix location in the bucket. Otherwise, your CTAS query fails with the exception "HIVE_PATH_ALREADY_EXISTS".If an existing Athena table is pointing to the Amazon S3 location that you want to use in your CTAS query, then do the following:Drop the Athena table.Delete the data in the key prefix location of the S3 bucket.

Related informationCTAS table propertiesConsiderations and limitations for CTAS queries
Question: How do I resolve the "RequestError: send request failed caused by: Post https://ssm.RegionID.amazonaws.com/: dial tcp IP:443: i/o timeout" SSM Agent log error?

I'm trying to register my Amazon Elastic Compute Cloud (Amazon EC2) instance as a managed instance with AWS Systems Manager. However, the instance fails to register and I receive a TCP timeout error message.

Short descriptionThe TCP timeout error indicates that one of the following issues is preventing the instance from registering:The instance is in a private subnet and uses the Systems Manager virtual private cloud (VPC) endpoint and a custom DNS server.The instance is in a private subnet and doesn't have access to the internet or to the Systems Manager endpoints.The instance is in a public subnet. The VPC security groups and network access control lists (network ACLs) aren't configured to allow outbound connections to the Systems Manager endpoints on port 443.The instance is behind a proxy, but SSM Agent isn't configured to communicate through an HTTP proxy and can't connect to the instance metadata server.You can view the TCP timeout error in the SSM Agent log on your instance located at the following paths:Linux and macOS/var/log/amazon/ssm/amazon-ssm-agent.log/var/log/amazon/ssm/errors.logWindows%PROGRAMDATA%\Amazon\SSM\Logs\amazon-ssm-agent.log%PROGRAMDATA%\Amazon\SSM\Logs\errors.log

ResolutionInstance in private subnet using Systems Manager endpoint and a custom DNSVPC endpoints only support Amazon-provided DNS through Amazon Route 53. To use your own DNS server, try one of the following:Use the conditional forwarder in your custom DNS server to forward any query for the domain amazonaws.com to the default VPC DNS resolver. For more information, see DHCP options sets.Set up the Route 53 resolver to resolve the DNS queries between the VPC and your network.Instance can't connect to the Systems Manager endpoints-or-VPC security groups and network ACL aren't configured to allow outbound connections on port 443-or-The instance is behind a proxy and can't connect to the instance metadata serviceFor troubleshooting steps, see Why is my EC2 instance not displaying as a managed node or showing a "Connection lost" status in Systems Manager?Related informationCreate VPC endpoints
Question: How do I resolve the "Resource timed out waiting for creation of physical resource" error when I create a resource using my resource provider type in CloudFormation?

When I use my Resource Provider type to create a resource in AWS CloudFormation, I receive the following error:"Resource timed out waiting for creation of physical resource"Short descriptionWhen a resource doesn't return its primaryIdentifier or Physical ID within 60 seconds, you receive the "Resource timed out waiting for creation of physical resource" error. This error occurs because the CreateHandler of your resource doesn't return the property that's specified as the primaryIdentifier in the organization-service-resource.json resource provider schema file.For other errors that are related to using a resource provider, see the following articles:How do I resolve the "Resource specification is invalid" error when I run the cfn generate command using the CloudFormation CLI in CloudFormation?How do I resolve the "Model validation failed (#: extraneous key [Key] is not permitted)" error in CloudFormation?How do I resolve the "Attribute 'Key' does not exist" error when I use the Fn::GetAtt function on my resource provider resource in CloudFormation?How do I resolve the "java.lang.ClassNotFoundException: com.example.package.resource.HandlerWrapper" error in CloudFormation?Resolution1.    In your organization-service-resource.json file, confirm that the primaryIdentifier definition uses the following format, where Id is a property that's defined in the properties section:"primaryIdentifier": [    "/properties/Id"]Note: The organization-service-resource.json format is located in the root directory of your project.2.    In your CreateHandler, set the primaryIdentifier property in the model object. For example:final ResourceModel model = request.getDesiredResourceState();model.setId("abcdxyz");return ProgressEvent.<ResourceModel, CallbackContext>builder()    .resourceModel(model)    .status(OperationStatus.SUCCESS)    .build();Related informationAWS CloudFormation CLI (from the GitHub website)
Question: How can I access an internal load balancer using VPC peering?

I want to connect to a load balancer in VPC A from my instance in VPC B. How can I access an internal load balancer using VPC peering?Short descriptionTo access an internal load balancer in VPC A from VPC B:Establish connectivity between VPC A and VPC B using VPC peering.Establish the necessary routes, security group rules, and network access control list (ACL) rules to allow traffic between the VPCs.

ResolutionUsing VPC peering, you can access internal load balancers (including Classic Load Balancers, Application Load Balancers, and Network Load Balancers) from another VPC.Establish connectivity between your VPCs using VPC peering.Note: VPC peering is available for intra-Region and inter-Region connectivity for local or cross-account VPCs.Verify that a route for the load balancer's subnets CIDR (or VPC CIDR) exists in the route table of the client subnet. The route must be directed towards the VPC peering ID of your VPCs. Similarly, verify that the route of the client subnet/VPC CIDR exists in the route table of the load balancer's subnets.Resolve the load balancer DNS name from your instance and use nslookup  to verify it.If you're using a Classic Load Balancer or an Application Load Balancer: verify that the security group and network ACL allow traffic from either the complete subnet/VPC of the instance or the specific instance IP:In the security group of the load balancer, allow only inbound traffic on the load balancer's listener port.For the network ACL of the subnet, allow ingress traffic from the instance IP or subnet/VPC for the load balancer's listener port. In egress, be sure that the Ephemeral port range (1024 to 65535) allows return traffic from the load balancer nodes to the instance.-or-If you're using a Network Load Balancer, ensure that the traffic is allowed in the security group of the target instancesNote: Modify your security groups or network ACLs, as needed. If you haven't modified the network ACLs, there's a default rule to allow all (0.0.0.0/0) traffic. In this case, you don't need to modify the network ACLs. However, it's an AWS security best practice to allow traffic to and from specific CIDR ranges.Check that the security group of the instance permits outbound traffic to the load balancer associated with the subnets or default (0.0.0.0/0).For the network ACL of the subnet, verify that there’s a rule in Egress to allow traffic for the load balancer's subnets on the load balancer's listener port. In Ingress, verify that there’s a rule to allow traffic to the instance IP/subnet on Ephemeral ports for response traffic .Note: If you haven't modified these default settings, you don't need to make any changes to the default outbound rule (0.0.0.0/0) for the security group or the default ALLOW ALL rule for the network ACL of the subnet with the instance. However, it's an AWS security best practice to allow traffic to and from specific CIDR ranges.