VishaalY/solutions-architect-hf-dataset huggingface dataset:
Question: What’s the difference between a hosted virtual interface (VIF) and a hosted connection?

I'm not sure if I should use a hosted virtual interface (VIF) or a hosted connection with AWS Direct Connect.

ResolutionWhen using Direct Connect, you can create a VIF in one of three ways:On the AWS account where the parent Direct Connect connection exists ("standard VIF")On another AWS account using the same parent Direct Connect connection, or a VIF purchased from an Amazon Partner Network (APN) partner who provisions it for you ("hosted VIF")A physical ethernet connection that an AWS Direct Connect partner provisions for youHosted VIFs can connect to public resources or an Amazon Virtual Private Cloud (Amazon VPC) in the same way as standard VIFs. However, the account that owns the VIF is different from the connection owner. Bandwidth is shared across all VIFs on the parent connection. For instructions on creating a hosted VIF, see Create a hosted virtual interface.Hosted connections allow an APN partner to create a Direct Connect connection for you. Complete bandwidth is allocated for the Direct Connect hosted connection. This allows creation of one VIF rather than having multiple VIFs on the same Direct Connect connection. The hosted Direct Connect connection values are 50 Mbps, 100 Mbps, 200 Mbps, 300 Mbps, 400 Mbps, 500 Mbps, 1 Gbps, 2 Gbps, 5 Gbps, and 10 Gbps. AWS Direct Connect partners that meet specific requirements can create a 1 Gbps, 2 Gbps, 5 Gbps or 10 Gbps hosted connection. Contact an AWS Partner Network (APN) to create the Direct Connect connection. Then, complete the steps to accept a hosted connection.Note: You can create only one VIF per hosted Direct Connect connection. You can't modify VLAN information to create a new VIF from the AWS Management Console. Each hosted connection is assigned a VLAN on creation by the partner. Each VIF on a given connection requires a unique VLAN tag that can be provisioned only by the partner. To get additional private or public VIFs, request another hosted connection from your APN partner. To create transit virtual interfaces, you must have 1 Gbps or larger of available hosted connection bandwidth.

Related informationWhat is AWS Direct Connect?
Question: How can I increase the maximum query string length in Amazon Athena?

When I run an Amazon Athena query with a long string, I get an error similar to the following: "'queryString' failed to satisfy constraint: Member must have length less than or equal to 262144 (Service: AmazonAthena; Status Code: 400; Error Code: InvalidRequestException;". I want to increase the maximum string length.

ResolutionMaximum query string length (262,144 bytes) is not an adjustable quota. This means that AWS Support can't increase the quota for you. Instead, split long queries into multiple, smaller queries. Here are some examples of how you can do that:Run multiple DDL statements. For example, assume that you're running an ALTER TABLE ADD PARTITION statement to add thousands of partitions to a table. If the query string is greater than 262,144 bytes, run multiple ALTER TABLE ADD PARTITION statements instead of one long one.Use views. Each view allows a query string length of 262,144 bytes.Use CREATE TABLE AS SELECT (CTAS) to break a long query into multiple queries and pass the results of one query to another query.You can also shorten table, column, and database names to decrease string length.

Related informationService quotas
Question: How does the ACM managed renewal process work with email-validated certificates?

I have an email-validated certificate with AWS Certificate Manager (ACM). How does ACM managed renewal work with email-validated certificates?ResolutionACM provides managed renewal for your Amazon-issued SSL/TLS certificates. An email-validated certificate is eligible for renewal if it's associated with AWS services integrated with AWS Certificate Manager.ACM certificates are valid for 13 months (395 days). To be renewed, email-validated certificates require an action by the domain owner. ACM begins sending renewal notices 45 days before expiration, using the domain's WHOIS mailbox addresses and to five common administrator addresses. The notifications contain a link that the domain owner can choose for renewal. After all listed domains are validated, ACM issues a renewed certificate with the same ARN. For more information, see Renewal for domains validated by email.You can use the AWS Certificate Manager console or the ACM API to request that ACM send you a domain validation email for your certificate renewal. For instructions, see Request a domain validation email message.You can also use automation with ACM certificates that are email-validated instead of manually validating certificates. For instructions, see Automating email validation.Note: These scenarios don't apply if you use DNS to validate domain ownership.

Related informationI validated my domain names using the AWS Certificate Manager (ACM) managed renewal process, but the status is still pending validation
Question: How are credits and promotions calculated in an organization in AWS Organizations?

I'm using AWS Organizations and joining or creating an organization, and my AWS account has active credits on it. How do my credits apply to the consolidated bill?ResolutionHere a few things to keep in mind if you are joining or creating an organization with active credits on your account:AWS applies credits under an account to the organization's consolidated bill, beginning the first full billing cycle after an account joins the organization.Credits on a standalone account are applied to usage costs incurred by the account before joining the organization. With credit sharing on, the remaining credit balance, if any, is applied across all applicable usage incurred by member accounts from the start of the next billing cycle.Credits redeemed on a standalone account at any time during the month of joining the organization are applied to the usage generated by the standalone account until joining the organization.To change this behavior, sign in to the payer account, and then disable credit sharing for the organization. For more information, see Sharing AWS credits.When you turn credit sharing off, be aware of the following that affects the rest of the current billing cycle:Bills are calculated based on the credit sharing preference on the last day of the month. If you turn credit sharing off before the last day of the month, then the bill for that billing cycle doesn't include the credits of member accounts.If the account was a member account in a different organization, then the credits on the member account apply to the bill of the former payer account until the end of the billing cycle. Any charges incurred by the member account after joining the new organization are billed to the current payer account.

Related informationAWS creditsConsolidated billing for AWS Organizations
Question: How do I pass ClientMetadata to Lambda triggers in Amazon Cognito?

I want to build an authentication workflow with Amazon Cognito APIs to pass client metadata to AWS Lambda triggers.

ResolutionWhen you call the InitiateAuth API with the ClientMetadata parameter to initiate user authentication in Amazon Cognito, ClientMetadata is passed to only these Lambda triggers:Pre sign-upPre authenticationMigrate userIn comparison, you must call the RespondToAuthChallenge API to include ClientMetadata in these Lambda triggers:Post authenticationPre token generationDefine auth challengeCreate auth challengeVerify auth challengeInclude the ClientMetadata parameter in the RespondToAuthChallenge API call to respond to any of these authentication challenges:Time-based one-time password (TOTP) multi-factor authentication (MFA)Short Message Service (SMS) for MFADevice Secure Remote Password (SRP)Custom authentication challengesAdditionally, the ClientMetadata parameter enhances custom workflows for Lambda function user pool triggers.Example RespondToAuthChallenge API call with the ClientMetadata parameterIn this example, an Amazon Cognito user pool is configured with an app client. A post authentication Lambda trigger is associated with the user pool.The Lambda function named lambda_handler prints the event it receives:import jsondef lambda_handler(event, context):# TODO implementprint(event)return eventImportant: Use logging carefully in production system to avoid exposing any secure data or secrets in Amazon CloudWatch.A test user is created in the user pool. Then, SMS for MFA is configured.The example InitiateAuth API call request initiates user sign in:aws cognito-idp initiate-auth --auth-flow USER_PASSWORD_AUTH --auth-parameters USERNAME=test,PASSWORD=Password@123 --client-id 1abcd2efgh34ij5klmnopq456rThe example InitiateAuth API call response:{  "ChallengeName": "SMS_MFA",  "Session": "1AbcDEfgXXXXX",  "ChallengeParameters": {    "CODE_DELIVERY_DELIVERY_MEDIUM": "SMS",    "CODE_DELIVERY_DESTINATION": "+********1234",    "USER_ID_FOR_SRP": "test"  }}The example RespondToAuthChallenge API call request submits MFA code and the ClientMetadata parameter includes any additional information to pass:aws cognito-idp respond-to-auth-challenge --client-id 9zyxw8vuts76rq5ponmlkj432i --challenge-name SMS_MFA --session "9ZyxWVutXXXXX" --challenge-responses USERNAME=test,SMS_MFA_CODE=654321 --client-metadata KeyName1='string',KeyName2='string'The example RespondToAuthChallenge API call response:{  "ChallengeParameters": {},  "AuthenticationResult": {    "AccessToken": "abXXXX",    "ExpiresIn": 3600,    "TokenType": "Bearer",    "RefreshToken": "abXX",    "IdToken": "abXXX"  }}After a user successfully authenticates and receives tokens from Amazon Cognito, the post authentication Lambda trigger is invoked.Find the post authentication Lambda trigger results under log events in the CloudWatch console. Look for the ClientMetadata parameter details in the event body.

Related informationCustom authentication challenge Lambda triggersCustomizing user pool workflows with Lambda triggers
Question: How do I troubleshoot issues with scaling triggers in Elastic Beanstalk?

My AWS Elastic Beanstalk environment isn't scaling the way that I expected.

Short descriptionThe Auto Scaling group in your Elastic Beanstalk environment uses two Amazon CloudWatch alarms to trigger scaling operations. Default Auto Scaling triggers are configured to scale under certain conditions. The triggers scale when the average outbound network traffic from each instance is higher than 6 MB or lower than 2 MB for five minutes.To use Amazon EC2 Auto Scaling effectively, you must configure scaling triggers that are appropriate for your application, instance type, and service requirements.Note: You can scale your environment based on several statistics, including latency, disk I/O, CPU utilization, and request count. In advanced scenarios, consider using .ebextensions based on custom metrics such as memory.Before you start the steps in the Resolution section, confirm the following:You have sufficient capacity for your Amazon Elastic Compute Cloud (Amazon EC2) instances to scale in your AWS Region. This capacity is based on the maximum number of instances that can be contained in the Auto Scaling group defined in your environment configuration.You have a cooldown period set, if necessary, based on the installation and configuration requirements of your application.You have identified the best metric for your environment to trigger by load testing with default CloudWatch metrics or load generating and testing with Locust.

ResolutionTo configure your scaling triggers, complete the steps using either the Elastic Beanstalk console or option settings:Configure scaling triggers in the Elastic Beanstalk console1.    Open the Elastic Beanstalk console, and then choose your environment.2.    In the navigation pane, choose Configuration.3.    For the Capacity category, choose Modify.4.    In the Scaling Triggers section, choose the triggering options based on your needs, and then choose Apply.Note: Elastic Beanstalk provides configuration options for Auto Scaling settings in the aws:autoscaling:trigger namespace. Settings in this namespace are organized by the resource that they apply to.Configure scaling triggers with option settingsModify your scaling configurations using .ebextensions in option settings.The following example modifies the scaling triggers to be based on CPU utilization. If CPU utilization across all instances is above 80 percent over three consecutive two-minute periods, then one instance is added to the Auto Scaling group. If CPU utilization across all instances is below 20 percent for the same period, then one instance is removed from the Auto Scaling group.option_settings:  aws:autoscaling:trigger:    MeasureName: CPUUtilization    Statistic: Average    Unit: Percent    Period: '2'    EvaluationPeriods: '3'    UpperThreshold: '80'    UpperBreachScaleIncrement: '1'    LowerThreshold: '20'    LowerBreachScaleIncrement: '-1'
Question: How do I resolve issues with Amazon DynamoDB auto scaling?

I turned on Amazon DynamoDB auto scaling on my table, but it's not working as expected. Or, my activity is still being throttled.

Short descriptionDynamoDB auto scaling creates Amazon CloudWatch alarms on your behalf. When an alarm is set off, the CloudWatch alarm invokes AWS Application Auto Scaling that then notifies DynamoDB to adjust the table's provisioned throughput capacity.DynamoDB auto scaling modifies provisioned throughput only when the workload stays depressed or elevated for several minutes. For example, you set the minimum read capacity units (RCUs) to 100 and the target utilization to 70 percent:DynamoDB auto scaling increases provisioned capacity when utilization exceeds 70 RCUs for at least 2 consecutive minutes.DynamoDB auto scaling decreases provisioned capacity when utilization is 20% or more below the target for 15 consecutive minutes (50 RCUs).

ResolutionTo troubleshoot problems with DynamoDB auto scaling:Be sure that you don't delete the CloudWatch alarms that DynamoDB auto scaling creates. When you delete alarms, DynamoDB auto scaling might not work as expected. If you accidentally delete the CloudWatch alarms, then turn off auto scaling and then activate it on the table. CloudWatch automatically recreates the alarms.Don't rely on DynamoDB auto scaling to handle occasional short-duration activity spikes. DynamoDB auto scaling works best when there are gradual increases or decreases in traffic. The table's built-in burst capacity handles occasional activity spikes.If the table's traffic is frequently unpredictable, then use an UpdateTable operation to set the billing mode to PAY_PER_REQUEST. This activates on-demand mode to adapt throughput to handle the workload.
Question: Why am I unable to mount my EFS file system on my EC2 instance?

I'm unable to mount my Amazon Elastic File System (Amazon EFS) file system on my Amazon Elastic Compute Cloud (Amazon EC2) instance.

ResolutionNote: If you receive errors when running the AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.There are multiple reasons you might not be able to mount your file system on your EC2 instance. For a list of possible mount issues and resolutions, see Troubleshooting mount issues.You can also follow the steps in the AWSSupport-CheckAndMountEFS AWS Systems Manager Automation document to check if the instance meets the prerequisites to mount the EFS on the EC2 instance. To run this automation, follow the instructions in Running a simple automation.

Related informationWalkthrough: Create an Amazon EFS file system and mount It on an Amazon EC2 instance using the AWS CLI
Question: How do I resolve the RegexSerDe error "Number of matching groups doesn't match the number of columns" in Amazon Athena?

I created an Amazon Athena table using RegexSerDe. When I query the table, I get this error: "Number of matching groups doesn't match the number of columns."ResolutionTo resolve this error, be sure that the number of capturing groups in the regex pattern matches the number of fields that were defined when you created the table in Athena. For example, here is a row of input data:64.xxx.xx.xx - - [07/Jul/2020:16:06:51 -0800] "GET /twiki/bin/rdiff/TWiki/NewUserTemplate?rev1=1.3&rev2=1.2 HTTP/1.1" 200 4523The row has seven fields. This is the correct regex pattern:^([0-9.]+) ([\\w.-]) ([\\w.-]) \\[([A-Za-z0-9:/]+ [+-][0-9]{4})\\] \"(.+?)\" ([0-9]{3}) ([0-9]+)$Note: RegexSerDe follows the Java standard. Because the backslash is an escape character in the Java String class, you must use a double backslash to define a single backslash. For example, to define \w, you must use \w in your regex.There are seven capturing groups in this regex pattern, and there are seven fields in the input data. When you query the table, RegexSerDe doesn't throw the "Number of matching groups doesn't match the number of columns" exception.To run a DDL statement, specify the regex capturing groups for SERDEPROPERTIES, as shown in the following example:CREATE EXTERNAL TABLE logs(  col1 string,  col2 string,  col3 string,  col4 string,  col5 string,  col6 string,  col7 string ) ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'WITH SERDEPROPERTIES (   "input.regex" = "^([0-9.]+) ([\\w.-]) ([\\w.-]) \\[([A-Za-z0-9:/]+ [+-][0-9]{4})\\] \"(.+?)\" ([0-9]{3}) ([0-9]+)$") LOCATION 's3://doc-example-bucket/path/'Related informationUsing a SerDe
Question: How do I determine the public IP address that my WorkSpace uses when I browse the internet?

As an Amazon WorkSpaces user, I want to find out the public IP address that my WorkSpace uses when I browse the internet. How can I do that?ResolutionThe steps to identify the public IP address that's used differs depending on how you access the internet from your WorkSpace. Use the following steps for your WorkSpace configuration.WorkSpace located in a public subnetOpen the WorkSpaces console.Select the arrow next to your WorkSpace ID to expand the WorkSpace details. Note the WorkSpace IP.Open the Amazon Elastic Compute Cloud (Amazon EC2) console. Then, choose Network Interfaces from the Network & Security section of the navigation pane.In the search box, enter the WorkSpace IP from step 2.Select the network interface associated with this WorkSpace IP address.From the Details tab, you can see the Public IPv4 address that your WorkSpace uses when you browse the internet.WorkSpace located in a private subnet using a NAT gatewayOpen the WorkSpaces console.Select the arrow next to your WorkSpace ID to expand the WorkSpace details. Note the WorkSpace IP.Open the Amazon EC2 console, and then choose Network Interfaces from the Network & Security section of the navigation pane.In the search box, enter the WorkSpace IP from step 2.Select the network interface associated with this WorkSpace IP address.From the Details tab, choose the hyperlinked Subnet ID.Select the subnet. From the Route table tab, you can see the NAT gateway associated with this subnet. Choose the hyperlinked security group.From the Details tab, you can see the Elastic IP address that your WorkSpace uses when you browse the internet.WorkSpace located in a private subnet using a NAT instanceOpen the WorkSpaces console.Select the arrow next to your WorkSpace ID to expand the WorkSpace details. Note the WorkSpace IP.Open the Amazon EC2 console, and then choose Network Interfaces from the Network & Security section of the navigation pane.In the search box, enter the WorkSpace IP from step 2.Select the network interface associated with this WorkSpace IP address.From the Details tab, choose the hyperlinked Subnet ID.Select the subnet. From the Route table tab, you can see the NAT instance elastic network interface associated with this subnet. Choose the hyperlinked network interface.From the Details tab, you can see the IPv4 Public IP address that your WorkSpace uses when you browse the internet.

Related informationProvide internet access from your WorkSpaceView details about a network interface
Question: How do I troubleshoot 503 errors returned while using Classic Load Balancer?

I'm seeing HTTP 503 errors in Classic Load Balancer access logs, CloudWatch metrics, or when hitting the load balancer's DNS name in the browser or from my clients.

Short descriptionMake sure that you registered backend instances in every Availability Zone that your Classic Load Balancer is configured to respond in. Make sure that the registered backend instances aren't failing health checks, and that they’re sized appropriately to handle the load your application requires.

ResolutionTo see the number of healthy backend instances behind your load balancer, check the HealthyHostCount and UnHealthyHostCount metrics in CloudWatch. If the CloudWatch metrics indicate that you have no healthy hosts, then you can troubleshoot the issue by checking the following:Make sure that your backend instances can respond to health checksIf the backend instances are running, but the UnhealthyHostCount metric indicates that the instances aren't healthy, verify that the application can respond to health check requests. For HTTP/HTTPS health checks, make sure that your load balancer is able receive a 200 response code from the back end. For layer 4 health checks, the load balancer marks the instance as healthy if the instance successfully completes a TCP handshake. For instructions, see Troubleshoot a Classic Load Balancer: Health checks.Make sure that your load balancer and backend instances can handle the loadCheck your load balancer and backend instances to verify that they’re able to handle the CPU usage, memory, disk, and number of connections your application requires.For example, check the SpilloverCount and SurgeQueueLength CloudWatch metrics. If SurgeQueueLength is at or near the maximum of 1,024 queued requests, or SpilloverCount is a non-zero number, then that indicates that the back end can’t serve requests as fast as they’re coming in, or isn’t able to serve requests at all.Also check CPUUtilization CloudWatch metrics for your backend instances—if you see that the CPU utilization is spiking to 100%, or is consistently high over long periods of time, then consider adding more backend instances, or resize the current instances to larger sizes. For instructions on checking other values, such as memory and disk usage, check the instance vendor’s documentation.

Related informationMonitor your Classic Load BalancerTroubleshoot a Classic Load Balancer: HTTP errors
Question: How do I find 5xx errors from API Gateway in my CloudWatch logs?

I keep seeing 5xx errors in my Amazon API Gateway CloudWatch metrics. How do I find specific 5xx errors from API Gateway in my Amazon CloudWatch logs?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.API Gateway CloudWatch metrics show the number of 5xx server-side errors captured in a given period. To identify specific 5xx errors from API Gateway, do the following:Enable execution logging and access logging in your Amazon CloudWatch Logs.Use either the filter-log-events AWS CLI command or CloudWatch Logs Insights to find specific 5xx errors from API Gateway.Note: If you're troubleshooting 504 errors from API Gateway, see How do I troubleshoot HTTP 504 errors from my API Gateway REST API?For information on how to use the filter-log-events command, see How do I find API Gateway REST API errors in my CloudWatch logs? For information on how to use CloudWatch Logs Insights, see Analyzing log data with CloudWatch Logs Insights.

Related informationSet up CloudWatch API logging using the API Gateway consoleView API Gateway log events in the CloudWatch console