VishaalY/solutions-architect-hf-dataset huggingface dataset:
Question: What protocols does CloudFront support?

What protocols can I use with my Amazon CloudFront distribution?ResolutionCloudFront supports HTTP, HTTPS, and Websockets as distribution protocols.HTTP versions for CloudFront and viewer connectionsCloudFront supports HTTP versions 1.0, 1.1 and 2 for connections to a viewer. By default, HTTP versions 1.0, 1.1 and 2 are turned on.To update HTTP settings, access the General tab of your distribution configuration. HTTP version 2 can be turned on or off. To use HTTP version 2, the viewer must support TLS 1.2 or later and Server Name Identification (SNI).HTTP versions for CloudFront and custom originsHTTP version 2 is not supported between CloudFront and custom origins. CloudFront forwards requests to a custom origin using HTTP version 1.1. For more information, see Request and response behavior for custom origins.Supported WebSockets connectionsCloudFront supports WebSocket connections globally with no required additional configuration. To establish a Websocket connection, the client sends an HTTP request using HTTP's upgrade semantics to change the protocol.By default, the WebSocket protocol uses port 80 for regular WebSocket connections and port 443 for WebSocket connections over TLS/SSL. The options that you choose for your CloudFront Viewer protocol policy and Protocol (custom origins only) apply to WebSocket connections and HTTP traffic. For more information, see Using WebSockets with CloudFront distributions.

Related informationValues that you specify when you create or update a distributionSupported protocols and ciphers between viewers and CloudFront
Question: How do I migrate a Lambda function to another AWS account or Region using the Lambda console?

I need to move an AWS Lambda function from one AWS account or AWS Region to another. How can I make those migrations using the Lambda console?Short descriptionTo migrate a Lambda function to another AWS account or AWS Region using the Lambda console, do the following:1.    Download the Lambda function’s deployment package.2.    Use the Lambda function’s deployment package to create a new Lambda function in another AWS account or Region.Note: You can also migrate a Lambda function using the AWS Command Line Interface (AWS CLI)  or an AWS Serverless Application Model (AWS SAM).

ResolutionDownload the Lambda function’s deployment package1.    In the Lambda console, choose Functions in the left panel.2.    Choose the name of the Lambda function that you want to migrate.3.    In the top right of the Lambda function window, choose the Actions dropdown, and then select Export Function.4.    In the Export Function window, choose Download deployment package.Use the Lambda function’s deployment package to create a new Lambda function in another AWS account or RegionNote: The deployment package contains only the Lambda function’s code. The rest of your function’s configurations, such as timeout and memory size, must be entered manually in the console when you create the new function. To migrate all your function’s code and configurations automatically, you can use an AWS SAM file.1.    In a new window, open the Lambda console using the AWS account that you want to migrate your function to.-or-Use the same AWS account, and then choose the AWS Region you want to migrate your function to.2.    Create a new Lambda function.Important: To create the new function, you must provide your function's name, runtime, and execution role.3.    After the function is created, choose the Code tab.4.    In the top right of the Code source window, choose Upload from.5.    Choose .zip file and then choose Upload.Note: If the downloaded deployment package is larger than 10 MB, then you must first upload it to an Amazon Simple Storage Service (Amazon S3) bucket. Then, choose Amazon S3 location instead of .zip file for step 5.6.    Choose the Lambda function's deployment package that you downloaded previously.7.    Choose Save.8.    Configure the new Lambda function’s settings to match the function that you’re migrating.9.    Invoke the function manually to test it.
Question: Why is my Amazon EBS volume stuck in the Optimizing state when I modify the volume?

I modified my Amazon Elastic Block Store (Amazon EBS) volume. However, the process is either slow or appears to be stuck in the Optimizing state for a long time.

Short descriptionWhen you modify an Amazon EBS volume, the volume goes through a sequence of states. These volume states include the modifying state, the optimizing state, and finally the completed state.If you increase the size of the volume, then the new size is available for use immediately after the modification. However, if the volume is in the Optimizing state, then the performance of the volume is in between the source and target configuration specifications. The performance of the volume is measured in terms of I/O operations per second and throughput.Modifying an EBS volume can take from a few minutes to a few hours depending on the configuration changes being applied. An EBS volume of size 1 TiB can typically take up to 6 hours to be modified. However, the same volume might take 24 hours or longer in other situations. The time it takes for volumes to be modified doesn't always scale linearly. Therefore, a larger volume might take less time, and a smaller volume might take more time.

ResolutionAfter a volume is modified, wait for at least six hours to modify the volume again. If the volume is still in the Optimizing state six hours after the modification, then you must wait until the volume completes the modification. If you must modify the volume while it's still in the Optimizing state, then use the following workaround solution:Use an Amazon EBS snapshot to restore a new EBS volume of the desired configurations. You can use an existing snapshot or create a new snapshot.Detach the current EBS volume that is in the Optimizing state.Attach the newly restored EBS volume to the instance, and use it thereafter.Note: The new EBS volumes restored from snapshots must be initialized for achieving maximum performance.

Related informationWhy isn’t my EBS volume increase reflected in my OS or Disk Management?
Question: Why are my Amazon Pinpoint voice message logs not populating?

I set up an Amazon Pinpoint voice event destination to log Amazon Pinpoint voice messages, but I'm not seeing any logs. Why are my Amazon Pinpoint voice message logs not populating, and how do I troubleshoot the issue?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.Verify that your requests to the SendVoiceMessage API operation include the name of your configuration setCheck the value for the ConfigurationSetName parameter in your requests to the SendVoiceMessage API operation. The request must contain the exact name of your configuration set.Example Python request to the SendVoiceMessage API operation that includes the ConfigurationSetName parameterresponse = client.send_voice_message(    DestinationPhoneNumber=destinationNumber,    OriginationPhoneNumber=originationNumber,    ConfigurationSetName="ConfigurationSetName",  # Pass the ConfigurationSetName here    Content={        "SSMLMessage": {            "LanguageCode": languageCode,            "VoiceId": voiceId,            "Text": ssmlMessage,        }    },)Verify that the Amazon Pinpoint voice event destination is activated1.    Run the following get-configuration-set-event-destinations AWS CLI command:Important: Replace <Pass_the_configuration_set_name> with your configuration set's name.aws pinpoint-sms-voice get-configuration-set-event-destinations --configuration-set-name <Pass_the_configuration_set_name>2.    In the command output, review the "Enabled" parameter. The event destination isn't activated if this parameter's value is false.Note: Logs don't write to an event destination if the destination isn't activated.3.    If the event destination isn't activated, then activate the event destination by running the following update-configuration-set-event-destination command:Important: Replace <Pass_the_configuration_set_name> with your configuration set's name. Replace <EventDestinationName> with your event destination's name. Replace <InputFileName> with your input request file's name. Make sure that your input request file's "Enabled" parameter is configured as true.aws pinpoint-sms-voice update-configuration-set-event-destination --configuration-set-name <Pass_the_configuration_set_name> --event-destination-name <EventDestinationName> --event-destination file://<InputFileName>.jsonExample input request file for an Amazon Kinesis Data Firehose stream event destination{    "Enabled": true,    "MatchingEventTypes": ["INITIATED_CALL","RINGING","ANSWERED","COMPLETED_CALL","BUSY","FAILED","NO_ANSWER"],    "KinesisFirehoseDestination": {        "DeliveryStreamArn": "arn:aws:firehose:<region>:<AccountID>:deliverystream/<Name_of_Kinesis_Firehose>",        "IamRoleArn": "arn:aws:iam::<AccountID>:role/service-role/<IAM_role_name>"    }}For more information about input request files, see How do I set up logging for Amazon Pinpoint voice messages?
Question: How do I associate an Elastic IP address with a WorkSpace?

I want to associate an Elastic IP address with a WorkSpace in Amazon WorkSpaces.

ResolutionTo associate an Elastic IP address with a WorkSpace, follow these steps:Open the Amazon WorkSpaces console.Select the WorkSpace, and then choose the Hide or Show details arrow to expand the WorkSpace details. Note the WorkSpace IP address.Open the Amazon Elastic Compute Cloud (Amazon EC2) console, and then choose Network Interfaces from the navigation pane.In the search bar, enter the WorkSpace IP address from step 2. Note the Network interface ID for the search result.From the Amazon EC2 console navigation pane, choose Elastic IPs. If you don't have an existing Elastic IP, or if your Elastic IP is already associated with an instance or network interface, then allocate a new IP address.Select the Elastic IP address that you want to associate with the WorkSpace, and then choose Actions, Associate Elastic IP address.For Resource type, choose Network interface.For Network interface, enter the Network interface ID from step 4.Choose Associate.To confirm that the Elastic IP address is associated with the WorkSpace, choose Network Interfaces from the Amazon EC2 console navigation pane. An address appears for IPv4 Public IP.

Related informationConfigure a VPC for WorkSpacesConfigure automatic public IP addressesAmazon WorkSpaces
Question: Can I use more than one payment method to pay my AWS charges?

I want to pay my AWS bill with multiple payment methods.

ResolutionYou can't divide a single AWS bill between multiple payment methods. However, you can add multiple payment methods to your AWS account, and then change the default payment method.If you receive bills from different AWS service providers or seller of records, you can set up a different payment method for each service provider bill.Example: If an AWS Organization account receives invoices from AWS Inc. and AWS EMEA (AWS Europe), each invoice can be paid using a different payment method. Also, you can set up a different payment method for your AWS Marketplace invoices.To assign more than one payment method to your AWS bills, see Managing your payment profiles.

Related informationWhat payment methods does AWS accept?How do I view past or current AWS payments?How do I retry an unsuccessful payment?How do change the default payment method associated with my AWS account?
Question: How do I share my AWS KMS keys across multiple AWS accounts?

I want to securely grant access to my AWS KMS key to another AWS account, so that it can be used to encrypt and decrypt data on that account. What is the best way to share my KMS key?ResolutionTo grant another account access to a KMS key, create an IAM policy on the secondary account that grants access to use the KMS key. For instructions, see Allowing users in other accounts to use a KMS key.You can also use automated monitoring tools to monitor your KMS keys.Note: It’s a best practice to grant least privilege access to your resources, especially when sharing them with accounts you don’t own.

Related informationAllow a user to encrypt and decrypt with specific KMS keysShare custom encryption keys more securely between accounts by using AWS Key Management Service
Question: Why isn't CloudFront following a cache behavior that I created?

I created a custom cache behavior for a specific URL path pattern on my distribution, but Amazon CloudFront isn't following the cache behavior. Why?ResolutionIf your CloudFront distribution isn't following a cache behavior that you created, check the following:Review your distribution's behaviors to be sure that there's a cache behavior for your requested path pattern. If the requested path pattern isn't correctly defined in a cache behavior, CloudFront uses the default cache behavior. For example, if a cache behavior has Path Pattern set to test/, then a request to example.com/test/file1.jpg follows the default cache behavior. The request won’t follow the behavior specified for test/ because the path pattern is missing a wildcard at the end of the path (test/*).Review the path pattern specified in the cache behavior to be sure that the capitalization is correct. Path patterns specified in CloudFront are case-sensitive. References to buckets or objects in Amazon Simple Storage Service (Amazon S3) are also case-sensitive. If a path pattern has incorrect capitalization and your default cache behavior doesn't cache the requested content, users might receive a "404 Not Found" error.If you recently made changes to the cache behavior and you want to serve the updated content before the existing content expires from the cache, then consider running an invalidation.Note: CloudFront doesn't generate 404 responses. If a requested object isn't found in a CloudFront cache, the request is sent to the origin and the origin generates the 404 response.

Related informationPath pattern
Question: Why can't I delete my AWS Directory Service directory?

I'm unable to delete my Simple AD, AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) directory, or AD Connector directory. How can I troubleshoot this?Short descriptionThe following are common issues that might occur when deleting a directory:You receive a message that you must deregister the service from the directory before you can delete it.You receive the error message "An Error Has Occurred. Directory can only be removed if there are no WorkSpaces assigned".

ResolutionBoth errors can occur if you have AWS applications enabled for the directory. For information on disabling AWS applications that are enabled for your directory, see Delete your directory.

Related informationAWS Directory Service FAQs
Question: How can I use a Lambda function to create an Amazon SageMaker notebook instance?

I want to create an Amazon SageMaker notebook instance using an AWS Lambda function.Resolution1.    Create an AWS Identity and Access Management (IAM) Lambda execution role with an attached policy that allows the sagemaker:CreateNotebookInstance action. For example, you can create a role that has the AmazonSageMakerFullAccess policy attached to it.2.    Create an Amazon SageMaker execution role. For more information about the permissions required for Amazon SageMaker execution roles, see CreateNotebookInstance API: execution role permissions.3.    Open the Lambda console.4.    Choose Create function.5.    Choose Author from scratch, and then configure the following options:For Name, enter a name for your function.For Runtime, choose one of the Python options.For Role, choose Choose an existing role.For Existing role, select the IAM role that allows the sagemaker:CreateNotebookInstance action. This is the role that you created in step 1.6.    Choose Create function.7.    In the Function code section, paste code similar to the following:import osimport boto3import timeINSTANCE_TYPE = os.environ['INSTANCE_TYPE']NOTEBOOK_NAME = os.environ['NOTEBOOK_NAME']ROLE=os.environ['ROLE']sagemaker = boto3.client('sagemaker')def lambda_handler(event, context):    sagemaker_notebook = sagemaker.create_notebook_instance(        NotebookInstanceName = NOTEBOOK_NAME +'-'+str(int(time.time())),        InstanceType = INSTANCE_TYPE,        RoleArn=ROLE    )print("New Amazon SageMaker notebook instance created.")8.    Scroll down to the Environment variables section, and then choose Edit.9.    Choose Add environment variable, and then create three environment variables with the following options. Environment variables allow you to store configuration settings without changing the function code.For Key, enter ROLE.For Value, enter the Amazon Resource Name (ARN) for the Amazon SageMaker execution role. This is the role that you created in step 2.For Key, enter INSTANCE_TYPE.For Value, enter the instance type for the notebook instance. For more information, see Supported instance types and Availability Zones.For Key, enter NOTEBOOK_NAME.For Value, enter a name for your notebook.10.    Choose Save to save the environment variables.11.    In the top-right corner of the function configuration page, choose Save, and then choose Test. The test event can be empty ("{}").12.    Open the Amazon SageMaker console to confirm that a notebook instance is initializing.Note: If the Lambda function test times out, open the Lambda function again. Scroll down to the Basic settings section, and then increase the timeout value. The default is three seconds.After you confirm that the function works, you can create a trigger to automatically run the function based on an event in another AWS service. For more information, see Using AWS Lambda with other services.
Question: How do I delete or terminate my Amazon EC2 resources?

I want to find all resources associated with the Amazon Elastic Compute Cloud (Amazon EC2) service and delete them.

Short descriptionAmazon EC2 resources fall under a few general billing categories. To stop accruing charges:Identify your active EC2 resources in all AWS Regions.Terminate (delete) all EC2 instances and related resources in all Regions.

ResolutionIdentify active resources in your AWS accountTo see your active resources and the Regions where they are provisioned, check your monthly bill in the Billing and Cost Management console.Use the AWSSupport-ListEC2Resources AWS Systems Manager Automation document to list your active EC2 resources. This automation document returns information on EC2 instances and related resources, such as Amazon Elastic Block Store (Amazon EBS) volumes, Elastic IP addresses, and Amazon EC2 Auto Scaling groups from the AWS Regions that you specify. By default, the information is gathered from all Regions and displayed in the output. To run this automation, follow the instructions in Running a simple automation.Delete or terminate EC2 resourcesTo terminate (delete) all your active resources, do the following in the respective Regions:Note: Deleted, terminated, or released resources can't be recovered.Stop or terminate all your EC2 instances and load balancers. Note: EC2 instances are visible in the console for a short time after they're terminated. You aren't billed for any instances that aren't in the running stateDelete your Auto Scaling infrastructure.Release all Dedicated Hosts.Delete all EBS volumes and EBS snapshots.Release all Elastic IP addresses.Deregister all Amazon Machine Images (AMIs).Terminate all Elastic Beanstalk environments.You can check the AWS Cost and Usage Report or AWS Cost Explorer to confirm that the resources are no longer generating charges.Note: Reserved Instances are billed as a flat fee each month. Instead, the fee is determined by the contract that you agreed to when you activated the Reserved Instance. Reserved Instances can't be canceled, but if you have a US bank account, you can list them for sale on the Reserved Instance Marketplace.The following EC2-related resources don't generate charges when used or provisioned to an account:Virtual private clouds (VPCs)Security groupsKey pairsElastic network interfacesAuto Scaling groupsNote: Amazon Lightsail and EC2 are separate services and are billed separately. For more information about Lightsail, see Lightsail docs.

Related informationWhy am I charged for Amazon EC2 when all my instances were terminated?Why can't I find an Amazon EC2 instance that I launched on my account?What do I do if I'm receiving a bill from AWS, but can't find the resources related to the charges?Why am I being billed for Elastic IP addresses when all my Amazon EC2 instances are terminated?I unintentionally incurred charges while using the Free Tier. How do I make sure that I'm not billed again?
Question: How can I automate the replacement of unhealthy Amazon EC2 instances in an Elastic Beanstalk environment?

I want to automate the replacement of unhealthy Amazon Elastic Compute Cloud (Amazon EC2) instances in my AWS Elastic Beanstalk environment.

Short descriptionBy default, the health check configuration of your Auto Scaling group is set as an EC2 type that performs a status check of EC2 instances. You must use a configuration file to automate the replacement of unhealthy EC2 instances. The configuration file changes the health check type of your instance's Auto Scaling group from EC2 to ELB.Keep the following in mind:Status checks cover only an EC2 instance's health, and not the health of your application, server, or any Docker containers running on the instance.If your application crashes, the load balancer removes the unhealthy instances from its target. However, your Auto Scaling group doesn't automatically replace the unhealthy instances marked by the load balancer.By changing the health check type from EC2 to ELB, you enable the Auto Scaling group to automatically replace the unhealthy instances. The unhealthy instances are replaced when the health check fails.Note: For more information on creating and deploying .ebextensions, see How do I customize my Elastic Beanstalk environment using .ebextensions?ResolutionThe following steps apply to environments with load balancers only.Use a configuration file to change the health check type of your instance's Auto Scaling group to ELB1.    Create a folder named .ebextensions in the root directory of your source bundle.2.    Create a resource-based .ebextension called a .config file. For example:Example .ebextensions/autoscaling.config===============================================Resources:  AWSEBAutoScalingGroup:    Type: AWS::AutoScaling::AutoScalingGroup    Properties:      HealthCheckType: ELB      HealthCheckGracePeriod: 300===============================================Note: HealthCheckGracePeriod refers to the time that Amazon EC2 Auto Scaling waits before checking the health status of an EC2 instance that's come into service.3.    Create a zip file for your updated application source bundle, and then deploy your application.Note: You can also deploy your application using eb deploy.Confirm that the health check type of your Auto Scaling group is set to ELB1.    Open the Amazon EC2 console.2.    In the navigation pane, choose Auto Scaling Groups.3.    For Filter, enter the environment ID of your Auto Scaling group, and then choose your Auto Scaling group from the list of results.4.    On the Details tab of your Auto Scaling group, confirm that Health Check Type is set to ELB.