Question: How do I monitor traffic in my VPC with flow logs?

How do I use flow logs to monitor the traffic to and from network interfaces in my virtual private cloud (VPC)?

Answer: "How do I use flow logs to monitor the traffic to and from network interfaces in my virtual private cloud (VPC)?Short descriptionVPC flow logs help you understand and track traffic to and from your VPC, a subnet, or a network interface. This data is also stored in Amazon CloudWatch for analysis at a later time.ResolutionReview the flow log limitations and determine if they’ll work for your use case. If so, create an AWS Identity and Access Management (IAM) role for your flow log, and then create a flow log.Note: Flow logs aren't updated in real time. It's a best practice to use flow logs for analysis and troubleshooting only.You can use this AWS Automation document to create flow logs to CloudWatch Logs or Amazon Simple Storage Service (Amazon S3). Be sure to have the required input parameters. For more information, see Publish flow logs to CloudWatch Logs and Publish flow logs to Amazon S3.Another option would be to deliver VPC flow logs to Amazon Kinesis Data Firehose. For more information, see Publish flow logs to Kinesis Data Firehose.Related informationInternetwork traffic privacy in Amazon VPCFollow"


Question: I'm using ElastiCache for Redis. Why are my Redis client read requests always read from or redirected to the primary node of a shard?

I'm using Amazon ElastiCache for Redis. Why are my Redis client read requests always read from or redirected to the primary node of a shard?

Answer: "I'm using Amazon ElastiCache for Redis. Why are my Redis client read requests always read from or redirected to the primary node of a shard?ResolutionAny node in a Redis cluster can receive queries from Redis clients. When a client sends a read/write query to a replica node, the node analyzes the request to confirm whether it is a single key or multi-key operation that belongs to the same hash slot of the shard. The default behavior of replica nodes in cluster-mode enabled clusters is to redirect all client read/write requests to an authoritative primary node of the shard that belongs to the key's hash slot. The replica node serves the read request only if that shard belongs to the hash slot and a readonly command is initiated by the client. This means that the replica node processes the request only if readonly is issued by the client before the request. Otherwise, the request is redirected to the primary node of the shard that the hash slot belongs to.Example1.    Log in to your cluster to set a key.172.31.21.72:6379> set key8 "This is testing for readonly"-> Redirected to slot [13004] located at 172.31.21.72:6379OK172.31.21.72:6379>2.    Connect to a replica node.In the following example, the readonly command isn't sent, and the request is redirected to a primary node.172.31.30.175:6379> info replication # Replication role:slave master_host:172.31.21.72 master_port:6379 master_link_status:up 172.31.30.175:637> CLUSTER KEYSLOT key8 (integer) 13004  172.31.30.175:637> get key8 (error) MOVED 13004 172.31.21.72:6379 172.31.30.175:637> get key8 -> Redirected to slot [13004] located at 172.31.21.72:6379 "This is testing for readonly" 172.31.21.72:6379>Note: The MOVED error shown in the preceding example occurs when the Redis cluster client isn't cluster aware and can't handle redirection requests to the primary node. For more information about the MOVED error, refer to Redis cluster specification - Redirection and resharding on the Redis.io website.In the following example, the readonly command is sent first, so the replica node processes the request instead of redirecting it to a primary node.172.31.30.175:6379> readonlyOK172.31.30.175:6379> get key8"This is testing for readonly"172.31.30.175:6379>The readonly command needs to be issued when the client connects to a node for the first time. The command is active only until the client reads keys from the same node. If the client connects to another replica node in the same or different shard, then you might need to issue a new readonly command.Follow"


Question: How can I create a CloudWatch alarm based on anomaly detection using the AWS CLI?

How can I create an Amazon CloudWatch alarm based on anomaly detection using the AWS Command Line Interface (AWS CLI)?

Answer: "How can I create an Amazon CloudWatch alarm based on anomaly detection using the AWS Command Line Interface (AWS CLI)?Short descriptionWhen you activate anomaly detection for a metric, CloudWatch applies machine-learning algorithms to the metric's historical data to create a model of the metric's expected values.The model generates two metrics that represent:The upper band of normal metric behaviorThe lower band of normal metric behavior, with a default value of two standard deviationsTo learn more, see How CloudWatch anomaly detection works.ResolutionNote: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent AWS CLI version.1.    Create a JSON file to set a CloudWatch alarm based on anomaly detection:{  "AlarmActions": [    "arn:aws:sns:us-east-1:397466294846:test1"  ],  "AlarmName": "MyAlarmName",  "AlarmDescription": "This alarm uses an anomaly detection model",  "Metrics": [    {      "Id": "m1",      "ReturnData": true,      "MetricStat": {        "Metric": {          "MetricName": "NetworkIn",          "Namespace": "AWS/EC2",          "Dimensions": [            {              "Name": "InstanceId",              "Value": "i-0e1830cdc0447f6b9"            }          ]        },        "Stat": "Average",        "Period": 60      }    },    {      "Id": "t1",      "Expression": "ANOMALY_DETECTION_BAND(m1, 3)"    }  ],  "EvaluationPeriods": 2,  "ThresholdMetricId": "t1",  "ComparisonOperator": "LessThanLowerOrGreaterThanUpperThreshold"}In this file:The Id of m1 is assigned to the NetworkIn metric of an instance. t1 is the anomaly detection model function for the NetworkIn metric. The model uses three standard deviations to set the width of the band.ThresholdMetricId is set to t1, and ComparisonOperator is set to LessThanLowerOrGreaterThanUpperThreshold. These settings make sure that the alarm goes into alarm state when the metric value is outside the anomaly model band in either direction for two consecutive evaluation periods.2.    Save the JSON file as anomaly-alarm.json. Then, run the following command to create an alarm with the anomaly detection band specified in the file:$ aws cloudwatch put-metric-alarm --cli-input-json file://anomaly-alarm.jsonThe model is generated when you finish creating the alarm. The band that you see in the graph initially is an approximation of the anomaly detection band. It might take up to 15 minutes for the anomaly detection band generated by the model to appear in the graph.Related informationCreating a CloudWatch alarm based on anomaly detectionFollow"


Question: I need a static IP address for my Application Load Balancer. How can I register an Application Load Balancer behind a Network Load Balancer?

Answer: "I need a static IP address for my Application Load Balancer.Short descriptionYou can't assign a static IP address to an Application Load Balancer. If your Application Load Balancer requires a static IP address, then it's a best practice to register it behind a Network Load Balancer. The static IP address that's assigned to a Network Load Balancer doesn't change and provides a fixed entry point for your Application Load Balancer.Note: The following resolution applies to the New Amazon Elastic Compute Cloud (Amazon EC2) Experience console. To complete the steps, toggle on this feature in the Amazon EC2 console.ResolutionCreate new target groups for TCP 80 and TCP 443 traffic, and register your Application Load Balancer as a targetTo create new target groups and register targets for Amazon EC2 instances, follow these steps:1.    Open the Amazon EC2 console.2.    In the navigation pane, expand Load Balancing, and then choose Target Groups.3.    Choose Create target group.4.    For Choose a target type, choose Application Load Balancer.5.    For Target group name, enter a name for the target group.6.    From the Protocol and Port dropdown lists, choose protocol TCP and port 80 for HTTP traffic.7.    From the VPC dropdown list, choose the virtual private cloud (VPC) for your Application Load Balancer.8.    From the Health Check protocol dropdown list, choose either HTTP or HTTPS for your Application Load Balancer that returns an HTTP 200–399 status.9.    Choose Next.10.    From the Application Load Balancer dropdown list, choose your Application Load Balancer.11.    Choose Create target group.12.    Repeat steps 3–11 to create an additional target group. When repeating step 6, choose TCP protocol and Port 443 to create another target group for HTTPS traffic.Create and configure a Network Load Balancer to forward HTTP and HTTPS traffic to your Application Load BalancerTo create and configure a Network Load Balancer to forward HTTP and HTTPS traffic to your Application Load Balancer, follow these steps:1.    Open the Amazon EC2 console.2.     In the navigation pane, expand Load Balancing, and then choose Load Balancers.3.    Choose Create a Load Balancer.4.    For Load balancer types, choose Network Load Balancer, and then choose Create.5.    For Load balancer name, enter a name for the Network Load Balancer.6.    In Scheme, choose either Internet-facing or Internal. You can use an internal Application Load Balancer with an internet-facing Network Load Balancer.7.    For IP address type, choose IPv4.8.    From the VPC dropdown list, choose your VPC.9.    For Mappings, choose one or more Availability Zones and subnets. Choose private subnets for Internal load balancers or public subnets for internet-facing load balancers.10.    From the IPv4 address dropdown list, choose either Assigned by AWS or Use an Elastic IP address.11.    From the Protocol and Port dropdown lists, choose protocol TCP and port 80 for HTTP traffic.12.    From the Default action dropdown list, choose the target group that contains your Application Load Balancer as registered targets.13.    Choose Add listener, and then repeat steps 11–12. Choose protocol TCP and port 443 with a default action that forwards traffic to the TCP 443 target group for your Application Load Balancer.14.    Choose Create load balancer.15.    Follow the instructions to test the load balancer.Note: To use HTTP to HTTPS redirects on your Application Load Balancer with this configuration, you must create two target groups. Create one Application Load Balancer target group for TCP 80 and another one for TCP 443.Configure your Application Load Balancer’s security groups and network access control lists (network ACLs) to allow health checks from the Network Load Balancer's private IP address.Related informationUsing AWS Lambda to activate static IP addresses for Application Load BalancersApplication Load Balancer now activates AWS PrivateLink and static IP addresses by direct integration with Network Load BalancerFollow"


Question: What should I consider before purchasing an Amazon EC2 Reserved Instance?

I plan to use a particular Amazon Elastic Compute Cloud (Amazon EC2) instance configuration for steady-state workflows over a long period of time. What factors should I consider before purchasing a matching Reserved Instance?

Answer: "I plan to use a particular Amazon Elastic Compute Cloud (Amazon EC2) instance configuration for steady-state workflows over a long period of time. What factors should I consider before purchasing a matching Reserved Instance?ResolutionConsider the following when deciding if Reserved Instances (RI) are right for you.Long term contractsReserved Instances have long contract terms (usually, one or three years). This means that you should purchase reservations only for an instance specification that you use over the long term.Billed as lump sumMost Reserved Instances are billed as a lump sum each month for each hour in that month. You're billed for this amount whether or not you ran an instance that matched your reservation. Reserved Instances provide the maximum discount for instance types that you use often and for long periods of time.If your account is in an organization's consolidated billing family, then additional considerations might apply. For more information, see How is the pricing benefit of a Reserved Instance applied across an organization's consolidated bill?Canceling and modifying a RIYou can't cancel a Reserved Instance. However, you can modify your Reserved Instance, subject to certain restrictions. For information about the available types of modifications, see Modify Reserved Instances.If you decide that you don't need an EC2 Reserved Instance after you purchase it and you have access to a US bank account, you can sell the Reserved Instance on the EC2 Reserved Instance Marketplace. For more details, see How do I sell an Amazon EC2 Reserved Instance on the Reserved Instance Marketplace?Capacity reservations and short-term discountsCapacity reservations apply only to zonal Reserved Instances, not Regional Reserved Instances. If you're interested in the capacity reservation but not the billing discount, then you might want to use On-Demand Capacity Reservations.For short-term discounts on EC2 instances, consider launching a Spot Instance instead.Pricing and purchasing an RIFor pricing information for EC2 Reserved Instances, see Amazon EC2 Reserved Instances Pricing.To purchase an EC2 Reserved Instance, see How do I purchase an Amazon EC2 Reserved Instance?After the reservation expires, the instance is charged as an On-Demand Instance. You can repurchase the RI to continue the discounted rate on your instance. You can schedule an EC2 Reserved Instance to renew automatically, see Can I schedule my EC2 Reserved Instance to renew automatically?Related informationInstance purchasing optionsFollow"


Question: How do I troubleshoot issues when I access an Amazon SageMaker Project in SageMaker Studio?

I want to troubleshoot issues when I access an Amazon SageMaker Project in SageMaker Studio.

Answer: "I want to troubleshoot issues when I access an Amazon SageMaker Project in SageMaker Studio.ResolutionSageMaker Project lets you manage and orchestrate end-to-end ML solutions. When you create or access projects from the Studio environment, you might have issues due to one or more of the following reasons:Missing permissionsNetwork issues in VPC only modeStudio user interface issuesMissing permissionsSageMaker Projects rely on AWS Service Catalog to use or create project templates and provision AWS resources for your accounts. Your Studio domain users can access or view these templates only when you grant Projects permissions.If your user doesn't have Projects permissions, then your user gets an error message similar to the following one:Amazon SageMaker project templates aren't enabled for your account.Contact your administrator to enable SageMaker project templates.To resolve this issue, be sure to grant Projects permissions for the administrator and domain execution role users.Also, you might have permission issues because one of the following items is missing, deleted, modified, or recreated manually:A service roles that was created when you activated SageMaker ProjectAmazon SageMaker JumpStartTo resolve this issue, complete the following steps to turn off SageMaker project templates and JumpStart:1.    Open the SageMaker console.2.    From the navigation pane, choose Domains.3.    Use the button next to the domain name to select your domain. Then, at the top of the Domains panel, choose Edit.4.    On the General settings page, choose Next.5.    Under SageMaker Projects and JumpStart, turn off the Enable Amazon SageMaker project templates and Amazon SageMaker JumpStart for this account. Also, turn off Enable Amazon SageMaker project templates and Amazon SageMaker JumpStart for Studio users switches.6.    Choose Next.7.    On RStudio settings page, choose Next.8.    On Amazon SageMaker Canvas settings page, choose Submit.9.    Delete all the roles that start with AmazonSageMakerServiceCatalogProduct*.10.  Use the preceding instructions to turn on the toggle switches that activate SageMaker project templates and JumpStart. This step creates several new roles for you. To view the list of your roles: Under Projects, choose the Apps tab, and then choose Control Panel.Note: To have the required permissions to access the AWS Service Catalog console, attach the managed policy SageMakerFullAccess to your Studio users' execution roles.Network issues in VPC only modeInternet access isn't active with the VPC only network access type. Therefore, you can't run a Studio notebook unless the following conditions are true:Your VPC has an interface endpoint to the SageMaker API and runtime or a NAT gateway with internet access.Your security groups allow outbound connections.If you don't need NAT gateway access for your SageMaker project, then you must create interface VPC endpoints (AWS PrivateLink) to connect to com.amazonaws.[region].servicecatalog. For example, if you're using Studio in the eu-west-1 AWS Region, then use com.amazonaws.eu-west-1.servicecatalog. For more information, see Requirements to use VPC only mode.To verify that your Studio's network settings allow connection to SageMaker API and Service Catalog endpoints, run the following commands from a Studio system terminal:Check access to SageMaker API endpoint:curl -v https://api.sagemaker.example-region.amazonaws.comCheck access to the Service Catalog endpoint in the desired Region:curl -v https://api.sagemaker.example-region.amazonaws.comIf you get the Connection timed out error when running these commands, then verify that your VPC network settings are configured for VPC only mode.View the list of available projects from the system terminal by running the following command:$ aws sagemaker list-projects --sort-by CreationTime --sort-order DescendingIf you can't view the same list in the SageMaker Studio interface, then make sure to update your Studio's domain. Then, do the following:1.    Launch SageMaker Studio.2.    In the left sidebar, choose Commands.3.    Search for Reset Application State in the Search bar, and then choose this option.Note: In JupyterLab 3, there's no Command Palette on the left sidebar by default. To add the Command Palette: On the menu, choose View, and then on the menu bar, choose Activate Command Palette. Or, you can use the keyboard shortcut command Ctrl + Shift + C.Follow"


Question: How can I resolve the "View is stale; it must be re-created" error in Athena?

"When I run a view query in Amazon Athena, I get a "stale view" error similar to the following: "SYNTAX_ERROR: line 1:15: View 'awsdatacatalog.mydatabase.myview' is stale; it must be re-created.""

Answer: "When I run a view query in Amazon Athena, I get a "stale view" error similar to the following: "SYNTAX_ERROR: line 1:15: View 'awsdatacatalog.mydatabase.myview' is stale; it must be re-created."ResolutionAthena reports a stale view under one of or more of the following conditions:The table or database that's specified in the view query doesn't exist.You tried to modify the table definition after you create the view.You tried to update the schema or metadata in a referenced table while recreating or updating the table.For example, your query fails with this error if you create a view and then run an ALTER TABLE ADD COLUMNS statement on the same table. The stale view error also happens if you run an AWS Glue crawler to update the table definition. For more information, see Considerations for views.To prevent "stale view" errors, recreate the view whenever you modify the underlying table or databases. You can also replace the view by adding the OR REPLACE clause in the CREATE VIEW statement. This clause lets you update the existing view by replacing it.Related informationWorking with viewsFollow"


Question: How do I use multiple values for individual parameters in an AWS CloudFormation template?

I want to create or update a stack from an AWS CloudFormation template using multiple values for individual parameters.

Answer: "I want to create or update a stack from an AWS CloudFormation template using multiple values for individual parameters.Short descriptionYou can pass multiple values for individual parameters in an AWS CloudFormation template using one of these ways:Use AWS-specific parameter types to select values from a prepopulated list of existing AWS values from an AWS accountUse CommaDelimitedList parameter types to specify your own valuesResolutionUse AWS-specific parameter types to select values from a pre-populated list of existing AWS values from an AWS accountImportant: AWS CloudFormation validates the input value that you select against existing values in your account.In these example AWS CloudFormation templates, the parameter with the SecurityGroups key specifies an AWS-specific parameter type that can accept multiple values for SecurityGroupIds.JSON template:{  "AWSTemplateFormatVersion": "2010-09-09",  "Parameters": {    "SecurityGroups": {      "Type": "List<AWS::EC2::SecurityGroup::Id>",      "Description": "The list of SecurityGroupIds in your Virtual Private Cloud (VPC)"    }  },  "Resources": {    "MyEC2Instance": {      "Type": "AWS::EC2::Instance",      "Properties": {        "ImageId": "ami-79fd7eee",        "KeyName": "testkey",        "SecurityGroupIds": {          "Ref": "SecurityGroups"        }      }    }  }}YAML template:AWSTemplateFormatVersion: 2010-09-09Parameters:  SecurityGroups:    Type: 'List<AWS::EC2::SecurityGroup::Id>'    Description: The list of SecurityGroupIds in your Virtual Private Cloud (VPC)Resources:  MyEC2Instance:    Type: 'AWS::EC2::Instance'    Properties:      ImageId: ami-79fd7eee      KeyName: testkey      SecurityGroupIds: !Ref SecurityGroupsTo deploy the stack using the AWS CLI, use the following command:Note: Replace StackName with the name of your stack. Replace TemplateFileName with the name of your file. For ParameterValuee, enter your security group ID.aws cloudformation create-stack --stack-name StackName --template-body file://TemplateFileName--parameters ParameterKey=SecurityGroups,ParameterValue="sg-0123456789\,sg-2345678901"Use CommaDelimitedList parameter types to enter input valuesIn the following AWS CloudFormation template examples, the parameter with the SecurityGroups key specifies a CommaDelimitedList type that can accept multiple values for SecurityGroupIds.JSON template:{  "AWSTemplateFormatVersion": "2010-09-09",  "Parameters": {    "SecurityGroups": {      "Type": "CommaDelimitedList",      "Description": "The list of SecurityGroupIds in your Virtual Private Cloud (VPC)",      "Default": "sg-a123fd85, sg-b456ge94"    }  },  "Resources": {    "MyEC2Instance": {      "Type": "AWS::EC2::Instance",      "Properties": {        "ImageId": "ami-79fd7eee",        "KeyName": "testkey",        "SecurityGroupIds": {          "Ref": "SecurityGroups"        }      }    }  }}YAML template:AWSTemplateFormatVersion: 2010-09-09Parameters:  SecurityGroups:    Type: CommaDelimitedList    Description: The list of SecurityGroupIds in your Virtual Private Cloud (VPC)    Default: sg-a123fd85, sg-b456ge94Resources:  MyEC2Instance:    Type: 'AWS::EC2::Instance'    Properties:      ImageId: ami-79fd7eee      KeyName: testkey      SecurityGroupIds: !Ref SecurityGroupsFollow"


Question: How can I troubleshoot high CPU utilization for Amazon RDS or Amazon Aurora PostgreSQL?

I want to identify and resolve the cause of high CPU use in Amazon Relational Database Service (Amazon RDS) or Amazon Aurora PostgreSQL-Compatible Edition.

Answer: "I want to identify and resolve the cause of high CPU use in Amazon Relational Database Service (Amazon RDS) or Amazon Aurora PostgreSQL-Compatible Edition.Short descriptionIf you see that your load has high CPU usage, you can use a combination of the following tools to identify the cause:Amazon CloudWatch metricsEnhanced Monitoring metricsPerformance Insights metricsNative PostgreSQL view and catalogs (such as pg_stat_statements, pg_stat_activity, and pg_stat_user_tables)Idle connections in the databaseAnalyze commandPostgreSQL logging parameters to log long-running queries, autovacuum, lock waits, and connection and disconnection requests. For more information, see How do I enable query logging using Amazon RDS for PostgreSQL?ResolutionAmazon CloudWatch metricsYou can use CloudWatch metrics to identify CPU patterns over extended periods. Compare the graphs WriteIOPs, ReadIOPs, ReadThroughput, and WriteThroughput with the CPU utilization to find the times when the workload caused high CPU.After identifying the timeframe, you can review the Enhanced Monitoring data associated with your DB instance. You can set Enhanced Monitoring to collect data at intervals of 1, 5, 10, 15, 30, or 60 seconds. Doing this allows you to collect data at a more granular level than CloudWatch.Enhanced MonitoringEnhanced Monitoring provides a view at the operating system (OS) level. This view can help identify the cause of a high CPU load at a granular level. For example, you can review the load average, CPU distribution (system% or nice%), and OS process list.Using Enhanced Monitoring, you can check the loadAverageMinute data in intervals of 1, 5, and 15 minutes. A load average that's greater than the number of vCPUs indicates that the instance is under a heavy load. Also, if the load average is less than the number of vCPUs for the DB instance class, CPU throttling might not be causing application latency. Check the load average to avoid false positives when diagnosing the cause of CPU usage.For example, suppose that you have a DB instance that's using a db.m5.2xlarge instance class with 3000 Provisioned IOPS that reaches the CPU limit. Then, you can review the following example metrics to identify the root cause of the high CPU usage. In the following example, the instance class has eight vCPUs associated with it. For the same load average, exceeding 170 indicates that the machine is under heavy load during the timeframe measured:Load Average MinuteFifteen170.25Five391.31One596.74CPU UtilizationUser (%)0.71System (%)4.9Nice (%)93.92Total (%)99.97Note: In Enhanced Monitoring, Nice% represents the amount of CPU being used by your workload against the database.After turning on Enhanced Monitoring, you can also check the OS process list that's associated with the DB instance. Enhanced monitoring shows a maximum of 100 processes. This can help you identify which processes have the largest impact on performance based on CPU and memory use.You can combine Enhanced Monitoring results with pg_stat_activity results to help identify the resource usage of queries.Performance InsightsYou can use Amazon RDS Performance Insights to identify the query that's responsible for the database load. You can do so by checking the SQL tab that corresponds to a particular timeframe.Native PostgreSQL view and catalogsAt the database-engine level, if the issue occurs in real time, you can use pg_stat_activity or pg_stat_statements. This can help you group the machines, clients, and IP addresses that send the most traffic. You can also use this data to check increases over time or Increases in application servers. You can also verify if an application server has stuck sessions or locking issues. For more information, see the PostgreSQL documentation for pg_stat_activity and pg_stat_statements.To turn on pg_stat_statements, modify the existing custom parameter group and set the following values:Add pg_stat_statements to shared_preload_librariestrack_activity_query_size = 4096pg_stat_statements.track = ALLpg_stat_statements.max = 10000Choose Apply Immediately, and reboot the DB instance. Then, run a command similar to the following on the database that you want to monitor:Note: The following example installs the extension in the "demo" database.demo=> select current_database();current_database------------------demo(1 row)     demo=> CREATE EXTENSION IF NOT EXISTS pg_stat_statements;After pg_stat_statements is set up, you can monitor the output using one of the following methods:List queries by total_time and see which query spends most time in the database for PostgreSQL versions 12 and earlier:SELECT total_time, queryFROM pg_stat_statementsORDER BY total_time DESC LIMIT 10;For PostgreSQL versions 13 and later:SELECT total_plan_time+total_exec_time as total_time, queryFROM pg_stat_statementsORDER BY 1 DESC LIMIT 10;List queries with less buffer cache hit ratio, run the following query for PostgreSQL versions 12 and earlier:SELECT query, calls, total_time, rows, 100.0 * shared_blks_hit / nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percentFROM pg_stat_statements ORDER BY total_time DESC LIMIT 10;For PostgreSQL versions 13 and later:SELECT query, calls, total_plan_time+total_exec_time as total_time, rows, 100.0 * shared_blks_hit / nullif(shared_blks_hit +shared_blks_read, 0) AS hit_percentFROM pg_stat_statements ORDER BY 3 DESC LIMIT 10;List queries on a per-execution basis to sample queries over time for PostgreSQL versions 12 and earlier:SELECT query, calls, total_time/calls as avg_time_ms, rows/calls as avg_rows,temp_blks_read/calls as avg_tmp_read, temp_blks_written/calls as avg_temp_writtenFROM pg_stat_statementsWHERE calls != 0ORDER BY total_time DESC LIMIT 10;For PostgreSQL versions 13 and later:SELECT query, calls, (total_plan_time+total_exec_time as total_time)/calls as avg_time_ms, rows/calls as avg_rows,temp_blks_read/calls as avg_tmp_read, temp_blks_written/calls as avg_temp_writtenFROM pg_stat_statementsWHERE calls != 0ORDER BY 3 DESC LIMIT 10;Idle connections in the databaseIdle connections in the database might consume compute resources, such as memory and CPU. When your instance has high CPU utilization, be sure to check for idle connections on the database. For more information, see Performance impact of idle PostgreSQL connections. You can check for idle connections by reviewing the OS process list using Enhanced Monitoring. However, this list shows a maximum of 100 processes.You can check for idle connection by running a few queries at the database level:Run the following queries to view current sessions that are idle and active:SELECT pid, datname, state, current_timestamp-least(query_start,xact_start) age, application_name, usename, queryFROM pg_stat_activityWHERE query != '<IDLE>'AND query NOT ILIKE '%pg_stat_activity%'AND usename!='rdsadmin'ORDER BY query_start desc;SELECT application_name,pid,wait_event_type,wait_event,current_timestamp-least(query_start,xact_start) AS runtime, query AS current_queryFROM pg_stat_activityWHERE not pid=pg_backend_pid()AND query NOT ILIKE '%pg_stat_activity%'AND usename!='rdsadmin';Run the following queries to get the connection counts per user and application name:postgres=> SELECT application_name,count(*) FROM pg_stat_activity GROUP BY application_name;    application_name    | count ------------------------+------- psql                   |     1 PostgreSQL JDBC Driver |     1                        |     5(3 rows)postgres=> SELECT usename,count(*) FROM pg_stat_activity GROUP BY usename; usename  | count ----------+------- master   |     4 user1    |     1 rdsadmin |     2(3 rows)After identifying the idle connections, end these connections by running either of the following queries:psql=> SELECT pg_terminate_backend(pid)   FROM pg_stat_activity   WHERE usename = 'example-username'   AND pid <> pg_backend_pid()   AND state in ('idle');-or-SELECT pg_terminate_backend (example-pid);If your application as designed causes too many connections, then consider changing it so that memory and CPU resources aren't spent managing these connections. You might either change the application to limit the number of connections or use a connection pooler such as PgBouncer. You can also use Amazon RDS Proxy, a managed service that allows you to set up connection pooling with a few clicks.Analyze commandThe Analyze command collects statistics about the contents of tables in the database and stores the results in the pg_statistic system catalog. Subsequently, the query planner uses these statistics to help determine the most efficient execution plans for queries. If you don't run Analyze frequently on tables in your database, then the queries might consume more compute resources. This is because of the stale statistics present in the system for the relations that you access. These issues occur under the following conditions:Autovacuum isn't running frequently.Analyze wasn't run after the major version upgrade.Autovacuum isn't running: Autovacuum is a daemon that automates the execution of VACUUM and ANALYZE commands. Autovacuum checks for bloated tables in the database and reclaims the space for reuse. The autovacuum daemon makes sure that the table statistics are updated regularly by running the Analyze operation whenever the set threshold of tuples is dead. This allows the query planner to use the most efficient query plan based on recent statistics. If autovacuum isn't running, the query planner might create sub-optimal query plans, leading to higher resource consumption by the queries. For more information, see the following:Understanding autovacuum in Amazon RDS for PostgreSQL environmentsA case study of tuning autovacuum in Amazon RDS for PostgreSQLRun the following query to get information on when autovacuum and autoanalyze were last run on the tables:SELECT relname, last_autovacuum, last_autoanalyze FROM pg_stat_user_tables;Analyze wasn't run after the major version upgrade: PostgreSQL databases typically encounter performance issues after any major engine version upgrade. A common reason for these issues is that Analyze operation isn't performed after the upgrade to refresh the pg_statistic table. Be sure to run the Analyze operation for every database in your RDS for PostgreSQL DB instance. Optimizer statistics aren't transferred during a major version upgrade. Therefore, you must regenerate all statistics to avoid performance issues due to higher resource utilization.Run the following command without any parameters to generate statistics for all regular tables in the current database after a major version upgrade:ANALYZE VERBOSEPostgreSQL logging parametersTurn on query logging using Amazon RDS for PostgreSQL. Then, check the PostgreSQL error logs to confirm that your log_min_duration_statement and log_statement parameters are set to appropriate values. For more information, see the PostgreSQL documentation for Error reporting and logging.Lower the CPU usageAfter you identify the queries causing the high CPU, you can use the following methods to further lower the CPU usage:To find opportunities for tuning, use EXPLAIN and EXPLAIN ANALYZE to identify the caveats. For more information, see the PostgreSQL documentation for EXPLAIN.If there is a query that's running repeatedly, consider using prepared statements to lower the pressure on your CPU. Repeated running of prepared statements caches the query plan. Therefore, the time for planning is much less for further runs because the plan is already in cache.Related informationBest practices for working with PostgreSQLFollow"


Question: How can I configure or modify node labeling with the Amazon EMR YARN Scheduler queue?

I want to configure or modify node labeling using the Amazon EMR Apache YARN Scheduler queue.

Answer: "I want to configure or modify node labeling using the Amazon EMR Apache YARN Scheduler queue.Short descriptionThe default YARN node label settings for EMR clusters are as follows:Amazon EMR version 5.19.x and above in Amazon EMR-5.x.x series:The YARN node labels feature is turned on by default. This means that CORE node label is created for core nodes with the following properties. YARN Application-Master containers are allocated only on core nodes. For all other containers, there isn't a partition restriction. You can allocate the containers on either core or task nodes.yarn.node-labels.enabled: trueyarn.node-labels.am.default-node-label-expression: 'CORE'Amazon EMR version 6.X and above:The YARN node labels feature is turned off by default. The application master processes can run on both core and task nodes.ResolutionNote: It's a best practice to perform changes in a test environment before proceeding in your production environment. Also, when you turn off the YARN node label feature, the Application-Master container launches in any node type, such as core or task. There's no restriction for task nodes. If you configure the task nodes with Spot Instances, then running jobs might fail if the task node goes down due to spot capacity constraint.Turn off the YARN labels feature in Amazon EMR version 5.19.x and above in Amazon EMR-5.x.x seriesTurn off the default YARN label feature when creating a new EMR cluster:1.    Add the following properties in the Edit software settings, Enter configuration section:[  {    "Classification": "yarn-site",    "Properties": {      "yarn.node-labels.enabled": "false",      "yarn.node-labels.am.default-node-label-expression": ""    }  }]2.    Create a script with the .sh extension using the following content, and upload it to an Amazon Simple Storage Service (Amazon S3) bucket.3.    In the Bootstrap Actions section, add the newly created script as a custom action and proceed with cluster creation.#!/bin/bashsudo sed -i 's/yarn rmadmin -addToClusterNodeLabels "CORE(exclusive=false)"/echo "NO LABELS"/g' /var/aws/emr/bigtop-deploy/puppet/modules/hadoop/manifests/init.pp4.    After the cluster creation completes, confirm that the change was applied by running the following command in the master node:yarn cluster --list-node-labelsThe following is the expected output of the preceding command showing an empty value for node labels:<<<<< Node Labels: >>>>>>Turn off the default YARN label feature in an existing EMR cluster:1.    Connect to the Amazon EMR primary node using SSH.2.    Create a backup of the existing yarn-site.xml file. The path is :/etc/hadoop/conf/yarn-site.xml.3.    Open the yarn-site.xml in file editor mode using the following command:sudo su vi yarn-site.xml4.    Change the yarn.node-labels.enabled property value to false.<property><name>yarn.node-labels.enabled</name><value>false</value></property>5.    Remove the value CORE in the property yarn.node-labels.am.default-node-label-expression as shown in the following example:<property>    <name>yarn.node-labels.am.default-node-label-expression</name>    <value></value>  </property>6.    Restart the YARN ResourceManger service:sudo systemctl restart hadoop-yarn-resourcemanager.servicesudo systemctl status hadoop-yarn-resourcemanager.service7.    Confirm that the change is applied successfully using the following command:yarn cluster --list-node-labelsThe following is the expected output of the preceding command showing an empty value for node labels:<<<<< Node Labels: >>>>>>Turn on the YARN labels feature in Amazon EMR version 6.x and aboveTurn on the YARN label feature when creating a new EMR cluster:1.    Add the following properties to the Edit software settings, Enter configuration section, and then proceed with cluster creation:[  {    "Classification": "yarn-site",    "Properties": {      "yarn.node-labels.enabled": "true",      "yarn.node-labels.am.default-node-label-expression": "CORE"    }  }]2.    After the cluster creation completes, confirm that the change is applied successfully by running the following command in the master node:yarn cluster --list-node-labelsThe following is the expected output of the preceding command:<<<<< Node Labels: <CORE:exclusivity=false>  >>>>>Turn on the YARN label feature in an existing EMR cluster:1.    From the Amazon EMR console, select Clusters, and then select the cluster that you want to edit.2.    Choose the Configurations tab.3.    Select the Edit in JSON option under the Reconfigure tab, and add the following properties.[  {    "Classification": "yarn-site",    "Properties": {      "yarn.node-labels.enabled": "true",      "yarn.node-labels.am.default-node-label-expression": "CORE"    }  }]4.    Select the Apply this configuration to all active instance groups option, and then save the changes.5.    Confirm that the change is applied by running the following command in the master node:yarn cluster --list-node-labelsThe following is the expected output of the preceding command:<<<<< Node Labels: <CORE:exclusivity=false>  >>>>>>Follow"


Question: How do I create a trust relationship between AWS Managed Microsoft AD and my existing on-premises AD domain?

I want to create a trust relationship between my on-premises domain and my AWS Directory Service for Microsoft Active Directory.

Answer: "I want to create a trust relationship between my on-premises domain and my AWS Directory Service for Microsoft Active Directory. Short descriptionA trust relationship is a link between two different domains, where one domain (the trusting domain) trusts another (the trusted domain). A one-way trust scenario allows the user accounts from the trusted domain to access resources in the trusting domain.AWS Managed Microsoft AD supports external and forest trust relationships with your existing on-premises domain in all three trust relationship directions:One-way incomingOne-way outgoingTwo-way (bidirectional)ResolutionTo create a trust relationship between your AWS Managed Microsoft AD and your on-premises domain, perform the following steps:Important: You must create the trust on the on-premises domain first. Then, create the trust on your AWS Managed Microsoft AD.Complete all prerequisite steps.Prepare your on-premises domain for the trust relationship.Prepare your AWS Managed Microsoft AD for the trust relationship.Create the trust relationship between your on-premises Active Directory and your AWS Managed Microsoft AD.If you have connectivity issues, use the AWS Systems Manager AWSSupport-TroubleshootDirectoryTrust Automation document. For more information, see Run an automation.Related informationTrust creation status reasonsWhat is AWS Directory Service?Follow"


Question: How do I troubleshoot issues related to blue/green deployments in Amazon ECS?

I want to troubleshoot issues related to blue/green deployments for services hosted on Amazon Elastic Container Service (Amazon ECS).

Answer: "I want to troubleshoot issues related to blue/green deployments for services hosted on Amazon Elastic Container Service (Amazon ECS).Short descriptionThe most common issues related to blue/green deployments for services hosted on Amazon ECS are the following:AWS Identity and Access Management (IAM) related issues:You're unable to create your ECS service because you're getting this error: Please create your Service role for CodeDeployYou're getting this error: **servicefailed to launch a task with (error ECS was unable to assume the rolethat was provided for this task. Please verify that the role being passed has the proper trust relationship and permissions and that your IAM user has permissions to pass this role)**Load balancer/ECS related issues:Your ECS service is failing to stabilize due to health check failures.You're getting this error: The ELB could not be updated due to the following error: Primary taskset target group must be behind listenerTraffic is still routed to the blue target group after successful deployment.Your ECS tasks running in the ECS Service are failing Application Load Balancer health checks only during a new GREEN deployment.Your ECS tasks are inconsistently failing Application Load Balancer health checks.Your ECS Service is unable to place a task because no container instance meets all the requirements. The closest matching container instance has insufficient CPU units available.AWS CloudFormation related issues (if you're performing blue/green deployment through CloudFormation):When creating a change set that triggers a blue/green deployment, CloudFormation stack fails with an Internal Failure error.You're getting an error when creating a change set to trigger the blue/green deployment: **'CodeDeployBlueGreenHook' of type AWS::CodeDeploy::BlueGreen failed with message: The TaskDefinition logical Id [] is the same between initial and final template, CodeDeploy can't perform BlueGreen style update properly**ResolutionIAM related issuesYou are unable to create your ECS Service because you get the error: Please create your Service role for CodeDeploy:You get this error because AWS CodeDeploy doesn't have the required IAM permissions to action the blue/green deployment strategy. You must grant the CodeDeploy service permissions to update your Amazon ECS service on your behalf.To troubleshoot this error, verify that your CodeDeploy IAM role is created correctly and has the required permissions.To create an IAM role for CodeDeploy, do the following:Open the IAM console.In the navigation pane, choose Roles.Choose Create roleIn the Select type of trusted entity section, choose AWS service, and then choose CodeDeploy.In the Select your use case section, choose CodeDeploy - ECS, and then choose Next:Permissions.Note: Keep the default AWSCodeDeployforECS policy. This policy includes the permissions that CodeDeploy requires for interacting correctly with Amazon ECS and other services.Choose Next: Tags.(Optional) Enter a tag name, and then choose Next: Review.For Role name, enter ecsCodeDeployRole.Choose Create role.You are getting the error: service failed to launch a task with (error ECS was unable to assume the role that was provided for this task: Verify that the IAM role being passed has the proper trust relationship and permissions and that your IAM user has permissions to pass this role):Check the IAM role returned by the error message to make sure that the Amazon Elastic Compute Cloud (Amazon EC2) instance has a trusted relationship for the ECS tasks service ecs-tasks.amazonaws.com. The trust relationship for your role must look similar to the following:{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Principal": {        "Service": [          "ec2.amazonaws.com",          "ecs-tasks.amazonaws.com"        ]      },      "Action": "sts:AssumeRole"    }  ]}Load balancer/ECS related issuesYour ECS service is failing to stabilize due to health check failures: Be sure that the port mappings of your task definitions are matching with the ports of your target groups. For more information, see How can I get my Amazon ECS tasks running using the Amazon EC2 launch type to pass the Application Load Balancer health check in Amazon ECS?You are getting the error: Error Message: The ELB could not be updated due to the following error: Primary taskset target group must be behind listener : You get this error when your Elastic Load Balancing listeners or target groups are misconfigured. Be sure that the ELB primary listener and test listener are both pointing to the primary target group that's currently serving your workloads.Traffic is still routed to the blue target group after successful deployment: CodeDeploy automatically updates the primary Listener of your load balancer to point to the green target group after the deployment is complete. However, CodeDeploy updates only the production listener that you specified. If CodeDeploy fails to switch traffic after the deployment, then your ELB listeners might be configured with the wrong traffic type. Be sure that you specified the correct protocol and port for the primary ELB listener.Your ECS tasks running in the ECS Service are failing Application Load Balancer health checks only during a new green deployment: Check whether any other ECS service is trying to register its tasks to the same green target group, causing a discrepancy. Update the load balancer configuration to make sure that only one ECS service or port is registered to one target group.Your ECS tasks are inconsistently failing Application Load Balancer health checks: This issue might happen when your containers are taking more than the expected time to start. Check your container application code to find the cause for the delay. To resolve this issue, optimize the application code. If you still can't resolve the issue, then include a health check grace period on your ECS Service so that the containers get enough time to start.Your ECS Service is unable to place a task because no container instance meets all of its requirements. The closest matching container instance has insufficient CPU units available: Be sure that you have enough container instance resources before performing a blue/green deployment.CloudFormation related issuesNote: These troubleshooting steps are applicable only if you're using CloudFormation for your blue/green deploymentWhen creating a change set that triggers a blue/green deployment, CloudFormation stack fails with an Internal Failure error: To mitigate this issue, use a CloudFormation service role and attach this role to your CloudFormation stack. Be sure that the service role has the necessary permissions to run all stack operations. Note that you can't remove the service role from the stack after the stack is created.**You're getting an error when creating a change set to trigger the blue/green deployment: 'CodeDeployBlueGreenHook' of type AWS::CodeDeploy::BlueGreen failed with message: The TaskDefinition logical Id [] is the same between initial and final template, CodeDeploy can't perform BlueGreen style update properly:**  When you specify a test listener that's already pointing to the green target group, then the CodeDeploy hook fails with this error. Be sure that your test listener isn't already pointing to the green target group before running the blue/green deployment.Important: Don't use the UpdateService API to cancel and roll back the blue/green deployment. Instead, use the CreateDeployment API. To roll back a deployment, use the deploy StopDeployment API.Related informationHow can I perform blue/green deployments for services hosted on Amazon ECS?Perform ECS blue/green deployments through CodeDeploy using AWS CloudFormationFollow"


Question: How can I restrict the IAM permissions of an Elastic Beanstalk user to specific applications?

I want to restrict the AWS Identity and Access Management (IAM) permissions of an AWS Elastic Beanstalk user to specific applications.

Answer: "I want to restrict the AWS Identity and Access Management (IAM) permissions of an AWS Elastic Beanstalk user to specific applications.Short descriptionUse an IAM policy to restrict the permissions of an Elastic Beanstalk user. An Elastic Beanstalk user can be an IAM user or role. The policy can restrict access to a specific application or applications.Resolution1.    Create an IAM policy that restricts access to your Elastic Beanstalk application. Use the following IAM policy as an example template.2.    Attach your IAM policy to the IAM user or role that you want to restrict access to a specific application or applications only.If you use a service that integrates with Elastic Beanstalk, such as Amazon Simple Storage Service (Amazon S3), then allow greater access with minimal restrictions. This is because of the following reasons:In Elastic Beanstalk, you can't directly restrict permissions to your application because the application structure is a collection of components. These components are things such as environments, versions, and environment configurations. However, you can restrict permissions more precisely using actions, resources, and condition keys. For a list of available condition keys that you can use to grant conditional access according to your use case, see Resources and conditions for Elastic Beanstalk actions.An IAM policy isn't an effective way to secure underlying resources. For example, you can restrict how users interact with Elastic Beanstalk APIs using the appropriate IAM policy. However, you can't prevent users with Elastic Beanstalk permissions from creating resources in other AWS services that are unrelated to Elastic Beanstalk.Some of the resources that Elastic Beanstalk integrates with don't support resource-level permissions. For more information, see AWS services that work with IAM.The following example policy is designed to grant full access to two Elastic Beanstalk applications, App1 and App2:{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Action": [        "elasticbeanstalk:UpdateApplicationVersion",        "elasticbeanstalk:CreateApplicationVersion",        "elasticbeanstalk:DeleteApplicationVersion"      ],      "Resource": "*",      "Condition": {        "StringEquals": {          "elasticbeanstalk:InApplication": [            "arn:aws:elasticbeanstalk:us-east-2:123456789012:application/My App1",            "arn:aws:elasticbeanstalk:us-east-2:123456789012:application/My App2"          ]        }      }    },    {      "Effect": "Allow",      "Action": [        "elasticbeanstalk:DescribeAccountAttributes",        "elasticbeanstalk:AbortEnvironmentUpdate",        "elasticbeanstalk:TerminateEnvironment",        "rds:*",        "elasticbeanstalk:ValidateConfigurationSettings",        "elasticbeanstalk:CheckDNSAvailability",        "autoscaling:*",        "elasticbeanstalk:RequestEnvironmentInfo",        "elasticbeanstalk:RebuildEnvironment",        "elasticbeanstalk:DescribeInstancesHealth",        "elasticbeanstalk:DescribeEnvironmentHealth",        "sns:*",        "elasticbeanstalk:RestartAppServer",        "s3:*",        "cloudformation:*",        "elasticloadbalancing:*",        "elasticbeanstalk:CreateStorageLocation",        "elasticbeanstalk:DescribeEnvironmentManagedActions",        "elasticbeanstalk:SwapEnvironmentCNAMEs",        "elasticbeanstalk:DescribeConfigurationOptions",        "elasticbeanstalk:ApplyEnvironmentManagedAction",        "cloudwatch:*",        "elasticbeanstalk:CreateEnvironment",        "elasticbeanstalk:List*",        "elasticbeanstalk:DeleteEnvironmentConfiguration",        "elasticbeanstalk:UpdateEnvironment",        "ec2:*",        "elasticbeanstalk:RetrieveEnvironmentInfo",        "elasticbeanstalk:DescribeConfigurationSettings",        "sqs:*",        "dynamodb:CreateTable",        "dynamodb:DescribeTable"      ],      "Resource": "*"    },    {      "Effect": "Allow",      "Action": [        "iam:*"      ],      "Resource": [        "arn:aws:iam::123456789012:role/aws-elasticbeanstalk-ec2-role",        "arn:aws:iam::123456789012:role/aws-elasticbeanstalk-service-role",        "arn:aws:iam::123456789012:instance-profile/aws-elasticbeanstalk-ec2-role"      ]    },    {      "Effect": "Allow",      "Action": [        "elasticbeanstalk:DescribeEvents",        "elasticbeanstalk:DescribeApplications",        "elasticbeanstalk:AddTags",        "elasticbeanstalk:ListPlatformVersions"      ],      "Resource": [        "arn:aws:elasticbeanstalk:us-east-2:123456789012:application/My App1",        "arn:aws:elasticbeanstalk:us-east-2:123456789012:application/My App2"      ]    },    {      "Effect": "Allow",      "Action": [        "elasticbeanstalk:AddTags",        "elasticbeanstalk:Describe*"      ],      "Resource": [        "arn:aws:elasticbeanstalk:*::platform/*",        "arn:aws:elasticbeanstalk:*:*:environment/*/*",        "arn:aws:elasticbeanstalk:*:*:application/*",        "arn:aws:elasticbeanstalk:*::solutionstack/*",        "arn:aws:elasticbeanstalk:*:*:applicationversion/*/*",        "arn:aws:elasticbeanstalk:*:*:configurationtemplate/*/*"      ],      "Condition": {        "StringEquals": {          "elasticbeanstalk:InApplication": [            "arn:aws:elasticbeanstalk:us-east-2:123456789012:application/My App1",            "arn:aws:elasticbeanstalk:us-east-2:123456789012:application/My App2"          ]        }      }    }  ]}For more use cases and examples, see Example policies based on resource permissions or Example policies based on managed policies.Follow"


Question: Why are some instance types disabled when I'm trying to launch an EC2 instance from an AMI?

I'm trying to launch an Amazon Elastic Compute Cloud (Amazon EC2) instance from an Amazon Machine Image (AMI). Why is the instance type I want to launch disabled?

Answer: "I'm trying to launch an Amazon Elastic Compute Cloud (Amazon EC2) instance from an Amazon Machine Image (AMI). Why is the instance type I want to launch disabled?Short descriptionThe instance types A1, T4g, M6g, C6g, and R6g use AWS Graviton processors. AWS Graviton processors use the aarch64 (ARM64) architecture instead of x86_64 (AMD64).ARM64 architecture uses a different set of CPU instructions than the instructions used by the x86_64 architecture family. These instruction sets provide a mechanism for sending commands to the processor. During software compilation, the human-readable software code converts to CPU instructions specific to a CPU architecture. Any CPU of that architecture type can use these CPU instructions. However, the CPU of one architecture type can't understand the instruction set of another type. So, an AMI compiled from one architecture runs only on the CPUs of that architecture type.ARM64 and x86_64 architectures use different instruction sets. This means that EC2 instances and AMIs created using the x86_64 architecture aren't compatible with instances use the ARM64 architecture. This incompatibility causes one of the following to happen when launching or changing instances types:When launching a Graviton instance type with your selected EC2 AMI, the launch wizard might display the new instance types as disabled.If you change the instance type of an already deployed EC2 instance that isn't currently using the new architecture type, you might receive an error. The error message is similar to the following:"'m6g.large' is not a valid instance type for instance 'i-xyz' of architecture 'x86_64'".To use a different architecture, first create a new EC2 instance or AMI.Note: An AMI might be incompatible with your instance type without enhanced networking enabled. For more information, see How do I enable and configure enhanced networking on my EC2 instances?ResolutionLaunching new instancesAll major Linux distributions are available on ARM architecture. To launch an instance using ARM architecture:Open the Amazon EC2 console.Choose Launch instance, Launch instance.Choose 64-bit (ARM) next to the AMI corresponding to the ARM version of your favorite distribution, and then choose Select.Complete launching the instance.After you start the instance, it behaves like any EC2 instance.Changing instance typesBecause of the different instruction sets, a direct instance type change isn't possible between architecture types. To migrate your system to the new architecture, do the following:Launch a new EC2 instance of your desired configuration.Migrate your application to the new EC2 instance.Related informationAWS Graviton processorFollow"


Question: Why is my Amazon Kinesis Data Analytics application restarting?

My Amazon Kinesis Data Analytics for Apache Flink application is restarting.

Answer: "My Amazon Kinesis Data Analytics for Apache Flink application is restarting.ResolutionWhen a task fails, the Apache Flink application restarts the failed task and other affected tasks to bring the job to a normal state.The following are some of the causes and respective troubleshooting steps for this condition:Code errors, such as NullPointer Exception and DataCast type, are generated at the task manager and bubbled up to the job manager. The application is then restarted from the latest checkpoint. To detect application restarts due to unhandled exceptions in the application, check Amazon CloudWatch metrics such as downtime. This metric displays a non-zero value during restart periods. To identify the causes for this condition, query your application logs for changes from your application's state from RUNNING to FAILED. For more information, see Analyze errors: Application task-related failures.When you get out-of-memory exceptions, the task manager can't send healthy heartbeat signals to the job manager, leading to a restart of the application. In this case, you might see errors, such as TimeoutException, FlinkException, or RemoteTransportException in the application logs. Check if the application is overloaded due to CPU or memory resource pressure.Be sure that the CloudWatch metrics fullRestarts and downtime have non-zero values.Check the metrics cpuUtilization and heapMemoryUtilization for unusual spikes.Check for unhandled exceptions in your application code.Check for checkpoint and savepoint failures. Monitor the CloudWatch metrics numOFFailedCheckpoints, lastCheckpointSize, and lastCheckpointDuration for spikes and stead increases.To resolve this issue, try the following:If you've enabled debug logs for the application, the consumption of application resources might be high. Reduce the amount of logging by temporarily enabling the debug logs only when investigating issues.Analyze the TaskManager thread dump in the Apache Flink dashboard. For example, you can identify the CPU-intensive processes from the thread dump.Review the Flame graphs that are constructed by sampling the stack traces several times. You can use the Flame graphs to do the following: visualize the overall application health, identify methods that consume the most CPU resources, and identify the series of calls on the stack that led to the execution of a particular method. Check for blocked calls using the off-CPU Flame graphs.If your application is under-provisioning a source or sink, your application might experience throttling errors when reading and writing to streaming services such as Kinesis Data Streams. This condition might eventually lead to application crash. Check the throughput for the source and sink using CloudWatch metrics such as WriteProvisionedThroughputExceeded and ReadProvisionedThroughputExceeded. Consider scaling up your data streams to accommodate the data volume by increasing the number of shards.The FlinkKinesisProducer uses the Kinesis Producer Library (KPL) to put data from a Flink stream to a Kinesis Data Stream. Errors, such as timeout, cause failures in KPL that might eventually lead to the restart of the Flink application. In such cases, you might see an increase in the buffering time and number of retries. You can tune the following configurations for KPL in such a way that the record don't expire: RecordMaxBufferedTime, RecordTtl, and RequestTimeout. Also, monitor important KPL metrics such as ErrorsByCode, RetriesPerRecord, and UserRecordsPending. When these metrics indicate that the application is restarting, use the filters in CloudWatch Logs Insights to know the exact reasons for the errors that led to the restart.Note that not all errors lead to an immediate restart of the application. For example, errors in the application code might result in the DAG workflow error. In this case, the directed acyclic graph (DAG) for your application doesn't get created. The application shuts down and doesn't restart immediately. Also, the application doesn't restart immediately when you get an "access denied" error.If the issue still persists, contact AWS Support and provide the following information:Application ARNInformation about the source and sink of your applicationCloudWatch logs for your applicationTime of issue in UTCRelevant thread dumps from the Flink dashboardRelated informationApplication is restartingFollow"


Question: How do I troubleshoot permissions errors from API Gateway HTTP APIs with a Lambda integration or Lambda authorizer?

"When I try to invoke my AWS Lambda function with an API Gateway HTTP API, I get an "Internal Server Error" message. In my Amazon CloudWatch Logs, I see either a "doesn't have permissions to call the integration" or "doesn't have permissions to call the authorizer" error."

Answer: "When I try to invoke my AWS Lambda function with an API Gateway HTTP API, I get an "Internal Server Error" message. In my Amazon CloudWatch Logs, I see either a "doesn't have permissions to call the integration" or "doesn't have permissions to call the authorizer" error.Short descriptionIf an API Gateway HTTP API tries to invoke a Lambda function without Lambda invoke permission, then API Gateway returns an "Internal Server Error" message. If you activated CloudWatch logging for your HTTP API, then API Gateway also logs one of the following error messages in your access logs:For HTTP APIs with a Lambda integration: "integrationError": "The IAM role configured on the integration or API Gateway doesn't have permissions to call the integration. Check the permissions and try again."For HTTP APIs with a Lambda authorizer: "authorizerError": "The IAM role configured on the authorizer or API Gateway doesn't have permissions to call the authorizer. Check the permissions and try again."To resolve these errors, take one of the following actions:Use the API Gateway console or AWS Command Line Interface (AWS CLI) to add a resource-based Lambda invoke permission to your HTTP API.-or-Configure an AWS Identity and Access Management (IAM) execution role that grants your HTTP API permission to invoke your function. For more information, see API Gateway permissions model for invoking an API.For more information on troubleshooting errors when using Lambda integrations with HTTP APIs, see Troubleshooting issues with HTTP API Lambda integrations.ResolutionNote: If you receive errors when running AWS CLI commands, make sure that you're using the most recent AWS CLI version.Use the API Gateway console to add Lambda invoke permission to an HTTP API with a Lambda integrationOpen the API Gateway console.On the APIs pane, choose the name of your HTTP API.In the left navigation pane, choose Integrations.Choose Manage integration.Find the name of your Lambda integration, and then choose the Edit button next to the name of your Lambda integration.For Invoke permissions, choose Grant API Gateway permission to invoke your Lambda function.Or, provide the IAM role ARN that API Gateway can use to invoke the Lambda function.Choose Save, and then choose Deploy the API to add the Lambda invoke permission to your API.Use AWS CLI to add Lambda invoke permission to an HTTP API with a Lambda integrationRun the following add-permission AWS CLI command:aws lambda add-permission \--function-name "$YOUR_FUNCTION_ARN" \--source-arn "arn:aws:execute-api:$API_GW_REGION:$YOUR_ACCOUNT:$API_GW_ID/*/$METHOD/$RESOURCE" \--principal apigateway.amazonaws.com \--statement-id $STATEMENT_ID \--action lambda:InvokeFunctionNote: Replace the function-name value with your Lambda function's ARN. Replace the source-arn value with the source ARN of your API. Replace the statement-id value with a statement identifier that differentiates the statement from others in the same policy.Use the API Gateway console to add Lambda invoke permission to an HTTP API with a Lambda authorizerOpen the API Gateway console.On the APIs pane, choose the name of your HTTP API.In the left navigation pane, choose Authorization.Choose Manage authorization.Find the name of your Lambda authorizer, and then choose the Edit button next to the name of your Lambda authorizer.For Invoke permissions, choose Automatically grant API Gateway permission to invoke your Lambda function.Or, provide the IAM role ARN that API Gateway can use to invoke the Lambda function.Choose Save, and then choose Deploy the API to add the Lambda invoke permission to your API.Use AWS CLI to add Lambda invoke permission to an HTTP API with a Lambda authorizerRun the following add-permission AWS CLI command:aws lambda add-permission \--function-name "$YOUR_FUNCTION_ARN" \--source-arn "arn:aws:execute-api:$API_GW_REGION:$YOUR_ACCOUNT:$API_GW_ID/authorizers/$AUTHORIZER_ID" \--principal apigateway.amazonaws.com \--statement-id $STATEMENT_ID \--action lambda:InvokeFunctionNote: Replace the function-name value with your Lambda function's ARN. Replace the source-arn value with the source ARN of your API. Replace the statement-id value with a statement identifier that differentiates the statement from others in the same policy.Follow"


Question: How can I turn on automatic encryption of new Amazon EBS volumes and snapshot copies created in my account?

"I'm manually encrypting new Amazon Elastic Block Storage (Amazon EBS) volumes that I create. But, I want to automatically encrypt new Amazon EBS volumes and snapshot copies."

Answer: "I'm manually encrypting new Amazon Elastic Block Storage (Amazon EBS) volumes that I create. But, I want to automatically encrypt new Amazon EBS volumes and snapshot copies.Short descriptionNewly created Amazon EBS volumes aren't encrypted by default. However, you can turn on default encryption for new EBS volumes and snapshot copies that are created within a specified Region. To turn on encryption by default, use the Amazon Elastic Compute Cloud (Amazon EC2) console.Before you turn on encryption by default, consider the following points:Encryption by default is a Region-specific setting. After you turn on encryption for a Region, you can't turn it off for individual volumes or snapshots in that Region.After you turn on encryption by default, you can launch an instance only if the instance type supports Amazon EBS encryption.Turning on encryption by default doesn't change any existing unencrypted or encrypted resources. It encrypts only volumes and snapshot copies that you create after turning on default encryption.If default encryption is turned on, and you’re experiencing delta replication failures when migrating services using AWS Server Migration Service, then turn off default encryption. For lift-and-shift migration, it's a best practice to use AWS Application Migration Service (AWS MGN).ResolutionOpen the Amazon EC2 console.In the navigation bar, select the Region.In the navigation pane, choose EC2 Dashboard.In the upper-right corner, choose Account Attributes, EBS encryption.Choose Manage.For Always encrypt new EBS volumes, choose Enable.Choose Default encryption key, and then select any of your keys to set as the default.Choose Update EBS encryption.Repeat these steps for other Regions as needed.Note: If you select the default service key (aws/ebs) as the default encryption key, then you can't share the encrypted volume across accounts. To learn more about AWS KMS keys, see AWS KMS concepts.Follow"


Question: How do I resolve the "No space left on device" error from AWS Batch?

I receive a "No space left on device" error message when my AWS Batch job fails. How do I resolve the issue?

Answer: "I receive a "No space left on device" error message when my AWS Batch job fails. How do I resolve the issue?Short descriptionAWS Batch can return a "No space left on device" error for two reasons:There's not enough disk space on your Docker volume hosted on Amazon Elastic Block Store (Amazon EBS).(For Amazon Linux 1 only) You've reached the default Docker storage limit of 10 GiB.To resolve the error, first verify that your Docker volume hosted on Amazon EBS has enough disk space. If there's not enough disk space, then increase the size of your Amazon EBS volume. If there is enough disk space, then increase the default Docker storage limit.Both solutions require creating a new custom launch template and a new compute environment. You can't add a new custom launch template to an existing compute environment in AWS Batch.Note: The Amazon Elastic Container Service (Amazon ECS) optimized Amazon Linux Amazon Machine Image (AMI) 1 is deprecated. The Amazon ECS optimized Amazon Linux 2 AMI is the default image used when you create a managed compute environment in AWS Batch. For more information, see AMI storage configuration. This article references Amazon Linux 1 for backward compatibility only.If you have an AWS Batch ComputeEnvironment that's using ECS Optimized Amazon Linux 1 AMIs to launch Amazon Elastic Compute Cloud (Amazon EC2) instances, it's a best practice to create a new ComputeEnvironment. AWS Batch then uses the latest available ECS Optimized Amazon Linux 2 AMI at the time of creation.If you see the "No space left on device" error for jobs running on an Amazon EC2 instance launched using ECS Optimized Amazon Linux 2 AMI, then increase the size of the root volume (/dev/xvda) to make more storage space available for the container.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. You can also use AWS CloudShell to run the following commands.Verify whether your Docker volume hosted on Amazon EBS has enough disk space or notFollow the instructions in the To determine the available storage for Docker section or AMI storage configuration.If there isn't enough disk space, then see the To increase the size of Amazon EBS volumes in AWS Batch section of this article.-or-If there is enough disk space, then see the (For Amazon Linux 1 only) To increase the default Docker storage limit section of this article.Increase the size of Amazon EBS volumes in AWS Batch1.    Create a new custom launch template that resizes (adds "VolumeSize" larger than current) the Docker data volume ( /dev/xvda on default ECS optimized AL2 image) on your AWS Batch compute resources. For instructions, see Launch template support.Note: If you're using Amazon Linux 1, then make sure that you enter both of the required Docker volumes (/dev/xvda and /dev/xvdcz) for the DeviceName value.2.    Create a new compute environment that uses the new launch template.Note: The associated Amazon EC2 instances show the new drive sizes when AWS Batch spins up the instances.(For Amazon Linux 1 only) To increase the default Docker storage limit1.    Create a new custom launch template using the MIME multi-part archive format that increases the default Docker storage limit. For more information, see Amazon EC2 user data in launch templates.Example MIME multi-part file that overrides the default Docker image settings for an AWS Batch compute resourceContent-Type: multipart/mixed; boundary="==BOUNDARY=="MIME-Version: 1.0--==BOUNDARY==Content-Type: text/cloud-boothook; charset="us-ascii"#cloud-boothook#!/bin/bashcloud-init-per once docker_options echo 'OPTIONS="${OPTIONS} --storage-opt dm.basesize=20G"' >> /etc/sysconfig/docker--==BOUNDARY==--Important: If you use the AWS CLI or an AWS SDK, you must first base64-encode the user data. Then, submit that string as the value of the UserData parameter when you call the CreateLaunchTemplate API.2.    Create a new compute environment that uses the new launch template.Follow"


Question: What do I need to do to update my SSL/TLS certificate for an Amazon RDS DB instance or Aurora DB cluster?

"I received an email that says the SSL/TLS certificate that is used by my Amazon Relational Database Service (Amazon RDS) DB instance or Amazon Aurora DB cluster is expiring on March 5, 2020. What do I need to do?"

Answer: "I received an email that says the SSL/TLS certificate that is used by my Amazon Relational Database Service (Amazon RDS) DB instance or Amazon Aurora DB cluster is expiring on March 5, 2020. What do I need to do?Short DescriptionAmazon RDS and Aurora SSL/TLS certificates that were created before January 14, 2020 are expiring on March 5, 2020. If your certificate expires, you can lose connectivity to your RDS DB instance or Aurora DB cluster.ResolutionTo find out whether your applications connect to Amazon RDS databases using SSL/TLS and for other troubleshooting steps, see the following AWS Database Blog post: Update your SSL/TLS certificates by March 5, 2020.To rotate your SSL/TLS certificate, first update your client application or service to include the new CA certificates in its trust store using the combined bundle that contains both the new and the old CA certificates. Then, update your RDS DB instances to use the new CA certificates. It's important to test the client and server before deploying the new SSL/TLS certificate to your production environment. For complete instructions for updating your SSL/TLS certificates, see the following:Rotating Your SSL/TLS Certificate for Amazon RDSRotating Your SSL/TLS Certificate for Amazon AuroraRelated InformationUsing SSL/TLS to Encrypt a Connection to a DB InstanceFollow"


Question: How can I upload and import an SSL certificate to AWS Identity and Access Management (IAM)?


Question: How can I secure the files in my Amazon S3 bucket?

I want to limit permissions to my Amazon Simple Storage Service (Amazon S3) resources and monitor the access to these resources.

Answer: "I want to limit permissions to my Amazon Simple Storage Service (Amazon S3) resources and monitor the access to these resources.Short descriptionTo make sure your files and Amazon S3 buckets are secure, follow these best practices:Restrict access to your S3 resources: When using AWS, restrict access to your resources to the people that absolutely need it. Follow the principle of least privilege.Monitor your S3 resources: Monitor your resources using AWS CloudTrail logs, S3 server access logging, AWS Config, AWS Identity and Access Management (IAM) Access Analyzer, Amazon Macie, Amazon CloudWatch, or AWS Trusted Advisor's S3 bucket permissions check.Use encryption to protect your data: Amazon S3 supports encryption during transmission, server-side encryption (SSE), and client-side encryption.ResolutionRestrict access to your S3 resourcesBy default, all S3 buckets are private and can be accessed only by users who are explicitly granted access.Restrict access to your S3 buckets or objects by doing the following:Writing IAM user policies that specify the users that can access specific buckets and objects. IAM policies provide a programmatic way to manage Amazon S3 permissions for multiple users. For more information about creating and testing user policies, see the AWS Policy Generator and IAM Policy Simulator.Writing bucket policies that define access to specific buckets and objects. You can use a bucket policy to grant access across AWS accounts, grant public or anonymous permissions, and allow or block access based on conditions. For more information about creating and testing bucket policies, see the AWS Policy Generator.Note: You can use a deny statement in a bucket policy to restrict access to specific IAM users. You can restrict access even if the users are granted access in an IAM policy.Using Amazon S3 Block Public Access as a centralized way to limit public access. Block Public Access settings override bucket policies and object permissions. Be sure to enable Block Public Access for all accounts and buckets that you don't want publicly accessible.Setting access control lists (ACLs) on your buckets and objects.Note: If you need a programmatic way to manage permissions, use IAM policies or bucket policies instead of ACLs. However, you can use ACLs when your bucket policy exceeds the 20 KB maximum file size. Or, you can use ACLs to grant access for Amazon S3 server access logs or Amazon CloudFront logs.Consider these best practices when you use ACLs to secure your resources:Be sure to review ACL permissions that allow Amazon S3 actions on a bucket or an object. For the list of ACL permissions and the actions that they allow, see What permissions can I grant?Be stringent about who gets Read and Write access to your buckets.Carefully consider your use case before granting Read access to the Everyone group because this allows anyone to access the bucket or object.Never allow Write access to the Everyone group. This setting allows anyone to add objects to your bucket, which you will then be billed for. This setting also allows anyone to delete objects in the bucket.Never allow Write access to the Any authenticated AWS user group. This group includes anyone with an active AWS account, not just IAM users in your account. To control access for IAM users on your account, use an IAM policy instead. For more information on how Amazon S3 evaluates IAM policies, see How Amazon S3 authorizes a request.In addition to using policies, Block Public Access, and ACLs, you can also restrict access to specific actions in these ways:Turn on MFA delete, which requires a user to authenticate using a multi-factor authentication (MFA) device before deleting an object or disabling bucket versioning.Set up MFA-protected API access, which requires that users authenticate with an AWS MFA device before they call certain Amazon S3 API operations.If you temporarily share an S3 object with another user, create a presigned URL to grant time-limited access to the object. For more information, see Sharing objects using presigned URLs.Monitor your S3 resourcesYou can enable logging and monitor your S3 resources in these ways:Configure AWS CloudTrail logs. By default, CloudTrail tracks only bucket-level actions. To track object-level actions (such as GetObject), enable Amazon S3 data events.Enable Amazon S3 server access logging. For more information on reviewing these logs, see Amazon S3 server access log format.Use AWS Config to monitor bucket ACLs and bucket policies for any violations that allow public read or write access. For more information, see s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited.Use AWS IAM Access Analyzer to help you review bucket or IAM policies that grant access to your S3 resources from another AWS account.Use Amazon Macie to automate the identification of sensitive data stored in your buckets, broad access to your buckets, and unencrypted buckets in your account.Use CloudTrail with other services, such as CloudWatch or AWS Lambda, to invoke specific processes when certain actions are taken on your S3 resources. For more information, see Log Amazon S3 object-level operations using CloudWatch Events.If you have a Business Support Plan or an Enterprise Support plan, you can use AWS Trusted Advisor's S3 bucket permissions check. This check notifies you about buckets with open access permissions.Note: This Trusted Advisor check doesn't monitor for bucket policies that override bucket ACLs.Use encryption to protect your dataIf your use case requires encryption during transmission, Amazon S3 supports the HTTPS protocol, which encrypts data in transit to and from Amazon S3. All AWS SDKs and AWS tools use HTTPS by default.Note: If you use third-party tools to interact with Amazon S3, then contact the developers to confirm if their tools also support the HTTPS protocol.If your use case requires encryption for data at rest, Amazon S3 offers server-side encryption (SSE). The SSE options include SSE-S3, SSE-KMS, or SSE-C. You can specify the SSE parameters when you write objects to the bucket. You can also enable default encryption on your bucket with SSE-S3 or SSE-KMS.If your use case requires client-side encryption, see Protecting data using client-side encryption.Related informationIdentity and access management in Amazon S3Data protection in Amazon S3How do I require users from other AWS accounts to use MFA to access my Amazon S3 buckets?How can I see who's been accessing my Amazon S3 buckets and objects?Follow"


Question: Why can't Amazon SES publish data to an Amazon SNS topic?

I got a notification from AWS telling me that Amazon Simple Email Service (Amazon SES) failed to publish data to my Amazon Simple Notification Service (Amazon SNS) topic.

Answer: "I got a notification from AWS telling me that Amazon Simple Email Service (Amazon SES) failed to publish data to my Amazon Simple Notification Service (Amazon SNS) topic.ResolutionCheck the following:Use the Amazon SNS console to check that the topic still exists. Be sure to review the AWS Region selector in the navigation bar—you must select the Region that you expect the SNS topic to be in. If the topic was deleted, create a new topic.Confirm that the SNS topic is in the same Region as the Amazon SES endpoint that you use to receive emails. For more information on this requirement, see SNS action.Check the SNS topic's access policy and confirm that the policy grants access from Amazon SES. For more information on SNS topic access policies, see Using the access policy language and Example cases for Amazon SNS access control.Check if the SNS topic is using server-side encryption (SSE). If the topic is using SSE, you must check the policy of the AWS Key Management Service (AWS KMS) encryption key that the SNS topic is using. Then, confirm that the key policy grants Amazon SES permissions to the encryption key.Related informationIdentity and access management in Amazon SNSFollow"


Question: How do I monitor the logs of multiple Amazon EC2 instances in AWS OpsWorks Stacks?

I want to track the logs of my Amazon Elastic Compute Cloud (Amazon EC2) instances in AWS OpsWorks Stacks. How do I do that?

Answer: "I want to track the logs of my Amazon Elastic Compute Cloud (Amazon EC2) instances in AWS OpsWorks Stacks. How do I do that?ResolutionTo monitor the logs of Amazon EC2 instances that are managed by OpsWorks Stacks, do the following:Activate Amazon CloudWatch Logs for your instances at the layer level in OpsWorks Stacks.Monitor the logs for your instances in the CloudWatch console.For more information, see Using Amazon CloudWatch Logs with AWS OpsWorks Stacks.Related informationGetting started with CloudWatch LogsFollow"


Question: How do I launch ECS instances with Amazon ECS-optimized AMIs?

I want to launch instances with Amazon Machine Images (AMIs) optimized for Amazon Elastic Container Service (Amazon ECS). How can I do that?

Answer: "I want to launch instances with Amazon Machine Images (AMIs) optimized for Amazon Elastic Container Service (Amazon ECS). How can I do that?Short descriptionTo launch Amazon ECS-optimized AMIs, you can choose from the following options:Launch an Amazon ECS-optimized container instance with an Amazon ECS-optimized AMI from the Amazon Elastic Compute Cloud (Amazon EC2) consoleAutomate the creation of your Amazon ECS-optimized AMIsResolutionLaunch an Amazon ECS-optimized container instance with an Amazon ECS-optimized AMIOpen the Amazon EC2 console.In the Create Instance section, choose Launch Instance.From the left navigation pane, choose AWS Marketplace. Then, enter ecs-optimized in the search bar.Choose one of the following AMI versions based on your needs: Amazon Linux AMI, Amazon Linux 2 AMI, Windows Server 2016, or Amazon Linux 2 AMI (ARM).Important: To get your Amazon ECS-optimized instance to join your Amazon ECS cluster, see Launching an Amazon ECS Linux container instance.Automate the creation of your Amazon ECS-optimized AMIsUse AWS Systems Manager parameters to automate and retrieve Amazon ECS-optimized AMI metadata.In the following example, the image_id sub-parameter returns the machine image AMI ID for only the current recommended Amazon Linux EC2-optimized AMI version in us-east-1.aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux/recommended/image_id --region us-east-1 --query "Parameters[0].Value"You can use the AMI ID to launch your Amazon Linux container instance in us-east-1. You can also modify the command to return the machine image for a specific version and AWS Region.Important: To use SSM parameters, run the most up-to-date version of the AWS Command Line Interface (AWS CLI).You can use SSM parameters as input parameters for AWS CloudFormation templates. See the following example:AWSTemplateFormatVersion: '2010-09-09'Parameters:  ImageId:    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>    Description: Use an Image from SSM Parameter Store    Default: /aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_idResources:  EC2Instance:    Type: AWS::EC2::Instance    Properties:      InstanceType: t3.micro      SecurityGroups: [!Ref 'EC2SecurityGroup']      ImageId: !Ref ImageId  EC2SecurityGroup:    Type: AWS::EC2::SecurityGroup    Properties:      GroupDescription: SSH access      SecurityGroupIngress:      - IpProtocol: tcp        FromPort: '22'        ToPort: '22'        CidrIp: 0.0.0.0/0Related informationAmazon Machine Images (AMI)Follow"


Question: Why did DB connections drop on my RDS DB instance?

"My Amazon Relational Database Service (Amazon RDS) database connections dropped suddenly, which caused unexpected downtime. Why did my DB connections drop?"

Answer: "My Amazon Relational Database Service (Amazon RDS) database connections dropped suddenly, which caused unexpected downtime. Why did my DB connections drop?ResolutionAmazon RDS DB connections can drop for various reasons. To understand the cause of the drop in your DB connections, determine whether the DB connections dropped during or outside of the maintenance window for your RDS DB instance.If DB connections drop during the RDS maintenance windowDuring the DB instance maintenance window, AWS performs maintenance activities that can lead to dropped DB connections.Auto Minor Version Upgrade (if enabled on Amazon RDS)When Amazon RDS designates a new preferred minor engine version and your DB instance is running an earlier version, Amazon RDS performs an upgrade during the scheduled maintenance window if you have the Auto Minor Version Upgrade feature turned on. This can lead to dropped DB connections during the minor version upgrade as any engine-level version upgrade involves RDS downtime.Hardware maintenanceAmazon RDS schedules hardware maintenance when the underlying hosts of your DB instances are running on degraded hardware. The hardware maintenance is performed during the maintenance window configured for the DB instances. Before maintenance is scheduled, you receive an email notification about scheduled hardware maintenance windows that includes the time of the maintenance and the Availability Zones that are affected.Operating system maintenanceAmazon RDS periodically performs updates of the underlying operating system during the maintenance window configured for your DB instance. If the operating system update involves downtime, Amazon RDS schedules the maintenance for the next maintenance window. If the operating system update isn't required maintenance, you can postpone the maintenance window by adjusting the preferred maintenance window. If maintenance is required, the operating system update can't be postponed, and the update is applied during the subsequent maintenance window.Modifications performed on Amazon RDS by selecting "Apply in Next Maintenance Window"When performing any modifications of your RDS configuration, you can choose whether you want to apply the modifications immediately or In the next maintenance window. If you choose to perform the modifications in the next maintenance window, then there is no immediate downtime. The following modifications might cause downtime when applied during the next maintenance window:Renaming DB instance identifiersModifying DB instance classesChanging the backup retention periodsModifying DB portsChanging the DB engine versionAttaching a new subnet groupRefer to DB instances settings information to understand the detailed settings available for modification along with the impact and downtime of DB instances.If DB connections dropped outside the RDS maintenance windowDB connections might drop if the DB connections reach the client/server side timeout.Client timeout parameters configured at the application endClient timeout parameters configured at the application end can lead to DB connections drop. If the processing time of a query is too long, then the session might terminate incorrectly from the client. To resolve this issue, increase the client's timeout setting.Server timeout parameters configured in the custom parameter group attached to Amazon RDSAggressively set TCP keepalives lead to client connection timeouts. Timeouts occur when the client is idle for the amount of time set in tcp_keepalives_idle and the number of messages set in tcp_keepalives_count. A timeout can also occur when a connection is waiting for a server response while long-running queries are running on the DB instance.If the idle_in_transaction_session_timeout is set to a lower value than the default 24 hours, then any session that has been idle for more than the configured value is ended. If you set this value aggressively, even if the queries running require more time to get a response from the server, then the connection drops when the session is idle for longer than the configured timeout value.Unplanned DB restart/failoverA transient issue with underlying hardware might lead to the loss of communication to the DB instance. A hardware issue might initiate failover in a Multi-AZ deployment and recovery in a Single-AZ deployment by replacing the underlying host. This issue might render the DB instance unhealthy because the RDS monitoring system couldn't communicate with the RDS instance to perform the health checks.A transient network issue affects the underlying host of your DB Instance. The internal monitoring system detects this issue and proactively initiates recovery for a Single-AZ deployment and failover for Multi-AZ deployments.The DB instance becomes unresponsive when a high DB load leads to a memory crunch in the database that prevents the RDS monitoring system from contacting the underlying host. To avoid a failover and restart of your DB instance due to database overload, configure the memory parameters on the DB instance appropriately.A transient issue with the underlying storage subsystem can led to elevated latency for an Amazon Elastic Block Store (Amazon EBS) volume, which is identified by an internal monitoring system. As a proactive measure, the monitoring system initiates recovery for a Single-AZ deployment. In a Multi-AZ deployment, a failover to secondary is performed.Related informationHow do I minimize downtime during required Amazon RDS maintenance?Working with operating system updatesHow do I resolve problems when connecting to my Amazon RDS DB instance?How do I perform the root cause analysis for a Multi-AZ failover and restart of my Amazon RDS instance?Follow"


Question: How do I use CloudTrail to see if a security group or resource was changed in my AWS account?

"For auditing purposes, I want to look for changes made to a security group in my Amazon Virtual Private Cloud (Amazon VPC). What's the best way to review security group changes in my AWS account?"

Answer: "For auditing purposes, I want to look for changes made to a security group in my Amazon Virtual Private Cloud (Amazon VPC). What's the best way to review security group changes in my AWS account?Short descriptionTo view and monitor the security group event history in your AWS account, you can use any of the following AWS services and features:AWS CloudTrail Event historyAmazon Athena queriesAWS Config configuration historyNote: The following are some examples of security group-related API calls:CreateSecurityGroupDeleteSecurityGroupAuthorizeSecurityGroupEgressAuthorizeSecurityGroupIngressRevokeSecurityGroupEgressRevokeSecurityGroupIngressResolutionTo use CloudTrail Event history to review security group changes in your AWS accountNote: You can use CloudTrail to search event history for the last 90 days.1.    Open the CloudTrail console.2.    Choose Event history.3.    In Filter, select the dropdown list. Then, choose Resource name.4.    In the Enter resource name text box, enter your resource's name (for example, sg-123456789).5.    For Time range, enter the desired time range. Then, choose Apply.6.    In Event time, expand the event. Then, choose View event.For more information, see Viewing CloudTrail events in the CloudTrail console.Example CloudTrail event history eventNote: In this example, an inbound rule allows TCP port 998 from 192.168.0.0/32.{    "eventVersion": "1.05",    "userIdentity": {        "type": "AssumedRole",        "principalId": "123456789:Bob",        "arn": "arn:aws:sts::123456789:assumed-role/123456789/Bob",        "accountId": "123456789",        "accessKeyId": "123456789",        "sessionContext": {            "attributes": {                "mfaAuthenticated": "false",                "creationDate": "2019-08-05T07:15:25Z"            },            "sessionIssuer": {                "type": "Role",                "principalId": "123456789",                "arn": "arn:aws:iam::123456789:role/123456789",                "accountId": "123456789",                "userName": "Bob"            }        }    },    "eventTime": "2019-08-05T07:16:31Z",    "eventSource": "ec2.amazonaws.com",    "eventName": "AuthorizeSecurityGroupIngress",    "awsRegion": "us-east-1",    "sourceIPAddress": "111.111.111.111",    "userAgent": "console.ec2.amazonaws.com",    "requestParameters": {        "groupId": "sg-123456789",        "ipPermissions": {            "items": [                {                    "ipProtocol": "tcp",                    "fromPort": 998,                    "toPort": 998,                    "groups": {},                    "ipRanges": {                        "items": [                            {                                "cidrIp": "192.168.0.0/32"                            }                        ]                    },                    "ipv6Ranges": {},                    "prefixListIds": {}                }            ]        }    },    "responseElements": {        "requestId": "65ada3c8-d72f-4366-a583-9a9586811111",        "_return": true    },    "requestID": "65ada3c8-d72f-4366-a583-9a9586811111",    "eventID": "6c604d53-d9c3-492e-a26a-a48ac3f711111",    "eventType": "AwsApiCall",    "recipientAccountId": "123456789"}To use Athena queries to review security group changes in your AWS accountNote: To use Athena to query CloudTrail Logs, you must have a trail configured to log to an Amazon Simple Storage Service (Amazon S3) bucket. You can use Athena to query CloudTrail Logs over the last 90 days.1.    Open the Athena console.2.    Choose Query Editor. The Athena query editor opens.3.    In the Athena query editor, enter a query based on your use case. Then, choose Run query.For more information, see Understanding CloudTrail Logs and Athena Tables.Example query to return all CloudTrail events for security group creation and deletionImportant: Replace example table name with your table name.SELECT *FROM example table nameWHERE (eventname = 'CreateSecurityGroup' or eventname = 'DeleteSecurityGroup')and eventtime > '2019-02-15T00:00:00Z'order by eventtime ascExample query to return all CloudTrail events for changes made to a specific security groupImportant: Replace example table name with your table name.SELECT *FROM example table nameWHERE (eventname like '%SecurityGroup%' and requestparameters like '%sg-123456789%')and eventtime > '2019-02-15T00:00:00Z'order by eventtime asc;To use AWS Config configuration history to review security group changes in your AWS accountNote: You can use AWS Config to view configuration history for security group event history beyond the default 90-day limit. You must have the AWS Config configuration recorder turned on. For more information, see Managing the configuration recorder.1.    Open the CloudTrail console.2.    Choose Event history.3.    In Filter, select the dropdown list. Then, choose Event name.4.    In the Enter event name text box, enter the type of event that you're searching for (for example, CreateSecurityGroup). Then, choose Apply.5.    In Event time, expand the event.6.    On the Resources Referenced pane, choose the clock icon in the Config timeline column to view the configuration timeline.For more information, see Viewing resources referenced with AWS Config.Follow"