Question: How do I view my AWS CloudHSM audit logs?

"I need to view or monitor AWS CloudHSM activity for compliance or security reasons. For example, I need to know when a user created or used a key."

Answer: "I need to view or monitor AWS CloudHSM activity for compliance or security reasons. For example, I need to know when a user created or used a key.Short descriptionCloudHSM sends audit logs collected by HSM instances to Amazon CloudWatch Logs. For more information, see Monitoring AWS CloudHSM logs.ResolutionFollow these instructions to view CloudHSM audit logs.Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.Get your HSM cluster IDNote: If you already know what your HSM cluster ID is, you can skip this step.1.    Run this AWS CLI command to get your HSM cluster IP address.cat /opt/cloudhsm/etc/cloudhsm_mgmt_util.cfg | grep hostname2.    Run this AWS CLI command.Note: Replace your-region with your AWS Region and your-ip-address with your HSM cluster IP address.aws cloudhsmv2 describe-clusters --region your-region --query 'Clusters[*].Hsms[?EniIp==`your-ip-address`].{ClusterId:ClusterId}'You receive an output similar to the following."ClusterID": "cluster-likphkxygsn"AWS Management Console1.    Open the CloudWatch console for your AWS Region.2.    In the navigation pane, choose Logs.3.    In Filter, enter the Log Group name prefix. For example, /aws/cloudhsm/cluster-likphkxygsn.4.    In Log Streams, choose the log stream for your HSM ID in your cluster. For example, hsm-nwbbiqbj4jk.Note: For more information about log groups, log streams, and using Filter events, see Viewing audit logs in CloudWatch logs.5.    Expand the log streams to display audit events collected from the HSM device.6.    To list successful CRYPTO_USER logins, enter:Opcode CN_LOGIN User Type CN_CRYPTO_USER Response SUCCESS7.    To list failed CRYPTO_USER logins, enter:Opcode CN_LOGIN User Type CN_CRYPTO_USER Response RET_USER_LOGIN_FAILURE8.    To list successful key deletion events, enter:Opcode CN_DESTROY_OBJECT Response SUCCESSThe opcode identifies the management command that ran on the HSM. For more information about HSM management commands in audit log events, see Audit log reference.AWS CLI1.    Use the describe-log-groups command to list the log group names.aws logs describe-log-groups --log-group-name-prefix "/aws/cloudhsm/cluster" --query 'logGroups[*].logGroupName'2.    Use this command to list successful CRYPTO_USER logins.aws logs  filter-log-events --log-group-name "/aws/cloudhsm/cluster-exampleabcd"  --log-stream-name-prefix <hsm-ID> --filter-pattern "Opcode CN_LOGIN User Type CN_CRYPTO_USERResponse SUCCESS"  --output text"3.    Use this command to list failed CRYPTO_USER logins.aws logs filter-log-events --log-group-name "/aws/cloudhsm/cluster-exampleabcd" --log-stream-name-prefix <hsm ID> --filter-pattern "Opcode CN_LOGIN User Type CN_CRYPTO_USER Response RET_USER_LOGIN_FAILURE"  --output text4.    Use this command to list successful key deletion.aws logs filter-log-events --log-group-name "/aws/cloudhsm/cluster-exampleabcd" --log-stream-name-prefix <hsm ID> --filter-pattern "Opcode CN_DESTROY_OBJECT Response SUCCESS" --output textFor more information, see Viewing HSM audit logs in CloudWatch logs.Related informationInterpreting HSM audit logsfilter-log-eventsFollow"


Question: Why can't I receive email notifications from my Amazon SNS topic?

I'm not receiving email notifications from my Amazon Simple Notification Service (Amazon SNS) topic.

Answer: "I'm not receiving email notifications from my Amazon Simple Notification Service (Amazon SNS) topic.ResolutionVerify that your email endpoint is in the confirmed stateNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you're using the most recent AWS CLI version.Use either the AWS Management Console or AWS CLI to verify the state of your email endpoint.AWS Management ConsoleOpen the Amazon SNS console.On the navigation pane, choose Topics, and then choose your topic.In the Subscriptions section of the topic page, find your email endpoint in the Endpoint column.In the Status column of your subscription, verify that the status is Confirmed. The status is confirmed when the email endpoint is successfully subscribed.Manually confirm the subscription in the Amazon SNS console. If you can't receive the confirmation email, complete the steps in the following sections.To re-request the confirmation email, select the subscription with your endpoint, and then choose Request confirmation.AWS CLIRun the list-subscriptions-by-topic AWS CLI command.Note: If there is no email endpoint in the Endpoint column, then that the endpoint was deleted.Check if email addresses can receive emails from external contactsTo check if the issue is limited to Amazon SNS, send a test email from an external provider to your destination email address. This helps you gauge what kind of traffic is allowed from external sources. Mailboxes within an organization are often limited to internal traffic.If the mailbox works and has no issues, then complete the steps in the Check for a firewall, spam filter, blockers, or filter policy section.Check for a firewall, spam filter, blockers, or filter policyComplete the following troubleshooting steps:Check with email administrators to see if the no-reply@sns.amazonaws.com address is filtered out by a firewall or spam filter.Tip: It's a best practice to add the no-reply@sns.amazonaws.com address to your mailbox allow list. For more information, see the Q: Do subscribers need to specifically configure their email settings to receive notifications from Amazon SNS? entry in Amazon SNS FAQs.If your emails are still filtered out as spam, check the mailbox rules for explicit denies that block your SNS topic email. You can also check if emails are routed to specific folders in the mailbox.To prevent individuals from unsubscribing all recipients of your SNS topic email, set up an authentication to unsubscribe.Note: You must have the required permissions to unsubscribe to your email endpoint. You can confirm the subscription with an authenticated user in the Amazon SNS console or with the AWS CLI.Check for a filter policy on the subscription:Open the Amazon SNS console.On the navigation pane, choose Subscriptions.In the search box, enter the email address or SNS topic that the email endpoint is subscribed to, and then choose your subscription in the results.For your email endpoint, choose the Subscription filter policy tab, and then look for a filter policy on the subscription in the Subscription filter policy section.Note: Amazon SNS compares the message attributes to the attributes in the filter policy when a message is sent to the endpoint. If the message attributes and the filter policy attributes don't align, the message won't be received on the email endpoint.Confirm you're not using the default AWS KMS key settingsAmazon SNS allows encryption at rest for topics. If the default AWS Key Management Service (AWS KMS) key is used for encryption, services (such as Amazon CloudWatch), can't publish messages to the SNS topic. The key policy of the default AWS KMS key for Amazon SNS doesn't allow these services to perform kms:Decrypt and kms:GenerateDataKey API calls. Because this key is AWS managed, you can't manually edit the policy.If you're encrypting your Amazon SNS topic, use a customer managed key. The customer managed key must include the following permissions under the Statement section of the key policy:{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Principal": {        "Service": "service.amazonaws.com"      },      "Action": [        "kms:GenerateDataKey*",        "kms:Decrypt"      ],      "Resource": "*"    }  ]}These permissions allow the services to publish messages to encrypted SNS topics.Follow"


Question: How do I close my AWS account?

I want to close or cancel my AWS account.

Answer: "I want to close or cancel my AWS account.Short descriptionFor security reasons, AWS Support can't close your AWS account on your behalf. Follow the instructions in the Resolution section to prepare your account for closing, and then close your account.ResolutionBefore closing your accountTroubleshoot common issuesTroubleshoot common issues that you might encounter with your account:For unintentional charges, see I unintentionally incurred charges while using the AWS Free Tier. How do I make sure that I'm not billed again?For concerns about account compromise, see What do I do if I notice unauthorized activity in my AWS account?For error messages related to closing your account, see Why do I get an error when I try to close my AWS account?Sign in to your account, and back up resourcesReview the following procedures, and take the necessary actions:If you didn't complete the account sign-up process, then complete it.Sign in as the AWS account root user. If you sign in to an account with an AWS Identity and Access Management (IAM) user or role, then you can't close the account.Back up any resources or data that you want to keep. For instructions about how to back up a particular resource, see the AWS documentation for that service.Use AWS Transfer Family to transfer data from Amazon Simple Storage Service (Amazon S3) or Amazon Elastic File System (Amazon EFS).For AWS Organizations accounts:By default, member accounts don't have a root password. Before you can sign in as the root user, you must reset the root user password for these accounts.If your account is the management account of an organization, then be sure to close or remove all member accounts from your organization. For more information, see Removing a member account from your organization and Impacts of closing an account.To close the payer account in an organization, first delete the organization.Terminate all your resourcesClosing your account might not automatically terminate all your active resources. You might continue to incur charges for some of your active resources, even after you close your account. You're charged for any usage fees that you incurred before closure.Find all your active resources, and terminate them. See the following documentation for instructions:Find all your active resources: How do I check for active resources that I no longer need on my AWS account?Terminate all your resources: How do I terminate active resources that I no longer need on my AWS account?Make sure that your billing information is up to dateReview the following billing information, and take the necessary actions:If you purchased subscriptions with ongoing payment commitments, then you're charged for these subscriptions until the plan term ends, even after you close your account. This applies to subscriptions such as, Amazon Elastic Compute Cloud (Amazon EC2) Reserved Instances (RIs) and Savings Plans.After you close your account, your designated payment method is charged for any usage fees that you incurred before closure. If applicable, refunds are issued through the same payment method.You must add a valid credit card, debit card, or other payment method to close your account.If you reopen your closed account within 90 days, you might be charged for any AWS services that you didn't terminate before you closed the account.Pay your outstanding billsView your outstanding bills, and pay them:Open the Billing and Cost Management console.In the navigation pane, choose Payments. You can see your overdue payments in the Payments Due section.Choose Verify and pay next to any unpaid bills.Close your accountTo close your AWS account, do the following:Sign in to the AWS Management Console as the root user of the account.In the navigation pane, choose your account name, and then choose Account.Scroll to the Close Account section.Read and understand the terms of closing your account.Choose Close Account.Within a few minutes, you receive email confirmation that your account is closed.You can choose to sign in to your account three days after closing the account to check if you terminated all the resources. Open the AWS Billing and Cost Management console to monitor whether you continue to incur charges. If you continue to incur charges after terminating all your resources, then contact AWS Support.After closing your accountYou can still sign in and file an AWS Support case, or contact Support for 90 days.After 90 days, AWS permanently deletes any content remaining in your account, and shuts down any AWS services that you didn't shut down. However, AWS might retain service attributes as long as necessary for billing and administration purposes. AWS retains your account information as described in the Privacy Notice. You can't permanently delete your account before 90 days. You can't reopen the account after 90 days.Note: The account resources in AWS China (Beijing) and AWS China (Ningxia) Regions are subject to the policies of their operating partners. The operating partners are Sinnet in the Beijing Region and NWCD in the Ningxia Region. Account closure procedures in China might take longer than in other AWS Regions.You can't use the same email address that was associated with your closed account to create new AWS accounts.Related informationClosing an accountWhy did I receive a bill after I closed my AWS account?What do I do if I receive a bill from AWS but can't find the resources related to the charges?The administrator of an AWS account has left the company. How do I access this account?Follow"


Question: How do I calculate the query charges in Amazon Redshift Spectrum?

"I want to calculate query charges in Amazon Redshift Spectrum when the data is scanned from Amazon Simple Storage Service (Amazon S3). How do I calculate the Redshift Spectrum query usage or cost, and what are some best practices to reduce the charges?"

Answer: "I want to calculate query charges in Amazon Redshift Spectrum when the data is scanned from Amazon Simple Storage Service (Amazon S3). How do I calculate the Redshift Spectrum query usage or cost, and what are some best practices to reduce the charges?Short descriptionPrerequisites:An Amazon Redshift cluster.An SQL client that's connected to your cluster to run SQL commands.Both the Amazon Redshift cluster and Amazon S3 bucket must be in the same Region.With Redshift Spectrum, you can run SQL queries directly against the data in S3. You are charged for the number of bytes scanned from S3. Additional charges (of $5 to $6.25 per TB of data scanned) can be incurred depending on the Region. Byte numbers are always rounded up to the next megabyte, with a minimum of 10 MB per query. For more information, see Amazon Redshift pricing.Note: There are no charges for Data Definition Language (DDL) statements like CREATE, ALTER, or DROP TABLE statements for managing partitions and failed queries.ResolutionTo calculate the estimated query cost (and to obtain a summary of all S3 queries that were run in Redshift Spectrum), use the SVL_S3QUERY_SUMMARY table. The s3_scanned_bytes column returns the number of bytes scanned from S3 sent to the Redshift Spectrum layer.UsageYou can run the query against SVL_S3QUERY_SUMMARY to determine the number of bytes transferred by queryID:SELECT s3_scanned_bytesFROM SVL_S3QUERY_SUMMARYWHERE query=<queryID>;To determine the sum of all bytes scanned from S3, use the following query:SELECT sum(s3_scanned_bytes)FROM SVL_S3QUERY_SUMMARY;You can also determine the sum of bytes for all queries from Redshift Spectrum in a specific time interval. The following example shows you how to calculate the sum of all bytes for queries that started running since the previous day:SELECT sum(s3_scanned_bytes)FROM SVL_S3QUERY_SUMMARYWHERE starttime >= current_date-1;If you run this query against an S3 bucket in the US East (N. Virginia) Region, Redshift Spectrum charges $5 per terabyte. If the sum for s3_scanned_bytes returns 621,900,000,000 bytes when querying SVL_S3QUERY_SUMMARY, you have 0.565614755032584 terabytes (when you convert from bytes to terabytes).621900000000 bytes = 621900000000/1024 = 607324218.75 kilobytes607324218.75 kilobytes = 607324218.75/1024 =  593090.057373046875 megabytes593090.057373046875  megabytes =  593090.057373046875 /1024 = 579.189509153366089 gigabytes579.189509153366089  gigabytes =  579.189509153366089/1024 = 0.565614755032584 terabytesIn this example, your usage is approximately 0.5657 terabytes. To calculate the usage cost of Redshift Spectrum, multiply it by the cost per terabyte:$5 * 0.5657= $2.83You can also use the following SQL query to calculate the Redshift Spectrum usage charges:SELECT   round(1.0*sum(s3_scanned_bytes/1024/1024/1024/1024),4) s3_scanned_tb,   round(1.0*5*sum(s3_scanned_bytes/1024/1024/1024/1024),2) cost_in_usd FROM SVL_S3QUERY_SUMMARY;In this example, the charges in Redshift Spectrum are queried against your S3 bucket for data scanned from the previous day.Note: All queries that scan up to 9.9 MB are rounded up and charged for 10 MB. There are no charges for failed or aborted queries.Additionally, system log tables (STL) retain only two to five days of log history, depending on log usage and available disk space. Therefore, it's a best practice to calculate the daily query charges and to store it in another table, retaining a record of transferred bytes. Here's an example:CREATE VIEW spectrum_cost ASSELECT starttime::date as date, xid, query, trim(usename) as user,   CASE WHEN s3_scanned_bytes < 10000000 then 10 ELSE s3_scanned_bytes/1024/1024 end as scanned_mb,   round(CASE WHEN s3_scanned_bytes < 10000000 then 10*(5.0/1024/1024)   ELSE (s3_scanned_bytes/1024/1024)*(5.0/1024/1024) end,5) as cost_$ FROM svl_s3query_summary s LEFT JOIN pg_user u ON userid=u.usesysid JOIN (select xid as x_xid,max(aborted) as x_aborted from svl_qlog group by xid) q ON s.xid=q.x_xid WHERE userid>1 AND x_aborted=0AND s.starttime >= current_date-1;Note: You can also use the CREATE TABLE query to calculate and store the data in another table. If you don't want to specify a time period, remove "current_date-1".Calculate the total sum of data scanned from S3 to Redshift Spectrum since the day before. Then, calculate the total estimate of charges by running the following query:SELECT current_date-1 as query_since, SUM(scanned_mb) as total_scanned_mb, SUM(cost_$) as total_cost_$FROM spectrum_cost;Result:  query_since | total_scanned_mb | total_cost_$--------------+------------------+--------------- 2020-05-15   |            5029  |      0.02515Redshift Spectrum best practicesTo reduce the query charges and to improve Redshift Spectrum's performance, consider the following best practices:Use cost controls for Redshift Spectrum and concurrency scaling features to monitor and control your usage.Use Optimized Data Formats to improve performance and lower costs. Use columnar data formats such as PARQUET and ORC to select only the columns you want to scan from S3.Load the data in S3 and use Redshift Spectrum if the data is infrequently accessed.When using multiple Amazon Redshift clusters to scale concurrency, terminate those clusters as soon as the jobs are complete.Cost controls and concurrency scaling for Redshift SpectrumBy using the cost controls and concurrency scaling feature for Redshift Spectrum, you can create daily, weekly, and monthly usage limits. When the usage limits are reached, Amazon Redshift automatically takes action based on the usage limits.To configure the cost control from the Amazon Redshift console, perform the following steps:1.    Sign in to the AWS Management Console.2.    Open the Amazon Redshift console.Note: You can also define and manage usage limits from the AWS Command Line Interface (AWS CLI) or Amazon Redshift API operations.3.    Choose Configure usage limit.4.    Update the following configuration settings:Time period (Daily/Weekly/Monthly)Usage limit (TB)Action (Alert/Log to system table/Disable feature)Note: The Action features can help you manage your usage limits.To configure the Concurrency Scaling usage limit, perform the following steps:1.    Sign in to the AWS Management Console.2.    Open the Amazon Redshift console.3.    Choose Concurrency scaling usage limit as your usage limit.4.    Update the following configuration settings:Time period (Daily/Weekly/Monthly)Usage limit (hh:mm)Action (Alert/Log to system table/Disable feature)Note: The Time period is in UTC time zone. For the Alert and Disable feature, you can also attach an Amazon Simple Notification Service (SNS) subscription to the alarm. Additionally, if you activate an alert using the Amazon Redshift console, an Amazon CloudWatch alarm is created automatically for those metrics.Additional cost control requirements and limitationsWhen managing your Redshift Spectrum usage and cost, be aware of the following requirements and limitations:Usage limits are available with supported versions 1.0.14677 or later.You can add up to 4 limits and actions per category (8 limits total).Redshift Spectrum is supported only in Regions where Redshift Spectrum and Concurrency Scaling are available.Only one limit per feature can use the Disable action.Usage limits persist until the usage limit definition itself or the cluster is deleted.If you create a limit in the middle of a period, the limit is measured from that point to the end of the defined period.If you are choosing log options, review the details in the STL_USAGE_CONTROL logs.Related informationManaging usage limits in Amazon RedshiftSVL_QLOGSystem tables and viewsBest practices for Amazon Redshift SpectrumFollow"


Question: How do I upgrade or downgrade the SQL Server engine edition in RDS for SQL Server?

I want to upgrade or downgrade the SQL Server engine edition in Relational Database Service (Amazon RDS) for SQL Server. How can I do this?

Answer: "I want to upgrade or downgrade the SQL Server engine edition in Relational Database Service (Amazon RDS) for SQL Server. How can I do this?Short descriptionAmazon RDS for SQL Server supports Express, Web, Standard, and Enterprise editions. You can't perform a SQL Server edition change as an in-place modification using the RDS console or using the AWS Command Line Interface (AWS CLI).To upgrade your SQL Server edition, create a snapshot and then restore using the higher engine edition. To downgrade, use one of these methods:Use the native backup and restore option in RDS for SQL Server.Use AWS Database Migration Service (AWS DMS).Import and export SQL Server data using other tools.ResolutionUpgrade the SQL Server engine editionTo upgrade the SQL Server engine edition, create an RDS snapshot and then restore from that snapshot. For upgrade limitations, see Microsoft SQL Server considerations.To upgrade using a snapshot, follow these steps:1.    Create a snapshot of the original RDS for SQL Server instance.2.    Restore the snapshot taken in Step 1, to create a new RDS instance. Change the required edition to the higher edition during the restore.3.    Rename or delete the original RDS for SQL Server instance to free up the DNS endpoint name for reuse. For more information, see the section Rename the RDS instance.For detailed instructions and steps on upgrading from Standard edition to Enterprise edition, see Modify an Amazon RDS for SQL Server instance from Standard Edition to Enterprise Edition.You can use the same snapshot and restore method for these upgrades:Standard edition to Enterprise editionWeb edition to Standard edition or Enterprise editionExpress edition to Web edition, Standard edition, or Enterprise editionImportant note: Snapshot restoration while upgrading the edition creates a new RDS for SQL Server instance. The new instance has a different RDS endpoint than the snapshot source instance.Downgrade the SQL Server editionIn-place downgrading of RDS for SQL Server instance from higher to lower editions isn't supported because of limitations with SQL Server as a product. However, you can downgrade your RDS for SQL Server edition in any one of these combinations following the workaround options mentioned later:Enterprise edition to Standard, Web, or Express editionStandard edition to Web or Express editionWeb edition to Express editionTo downgrade the RDS for SQL Server edition use one of these options:Option 1: Use the native backup and restore option in RDS for SQL ServerNote: You can also use this option to move databases from lower to higher editions of RDS instances.Native backup and restore creates a full backup of the databases on the existing source RDS for SQL Server instance. Store the backups on Amazon Simple Storage Service (Amazon S3) and then restore the backup files onto a new target RDS instance.To downgrade from a source Enterprise instance to a target Standard instance, follow these steps:1.    Create a new RDS for SQL Server with Standard edition SQL Server. This is the new target instance.2.    Add the native backup and restore option on the source Enterprise and target Standard edition instances.3.    Back up each user database on the source (Enterprise) instance to an S3 bucket.4.    Run the sys.dm_dm_persisted_sku-features (Transact-SQL) query on each database on the source instance. This query checks if there are any features currently in use that are bound to the higher edition. Features bound to the higher edition might not work when you restore the databases on to the lower edition target instance.USE [database-name]    GO    SELECT feature_name FROM sys.dm_db_persisted_sku_features;    GO5.    Restore the backups from the S3 bucket to the target (Standard) RDS instance.6.    Make sure to create the required logins and users on the target RDS instance databases. Also create the appropriate security group and attach the appropriate parameter-option groups. These are the same as the source RDS instance.Note: You can use the preceding steps to export and import databases across any editions of SQL Server on RDS.Option 2: Use AWS DMSNote: You can use also use this option to move databases from lower to higher editions of RDS instances.Use AWS DMS to migrate your databases. AWS DMS also replicates ongoing changes from the higher edition instance (the source endpoint) to the lower edition instance (the target endpoint).AWS DMS allows unidirectional replication, bulk-load tables, and captures data changes (if supported by the source and target RDS for SQL Server instance versions).For more information, see these topics:Using a Microsoft SQL Server database as a source for AWS DMSUsing a Microsoft SQL Server database as a target for AWS Database Migration ServiceLimitations on using SQL Server as a source for AWS DMSMigrating your SQL Server database to Amazon RDS for SQL Server using AWS DMSOption 3: Import and export SQL Server data using other toolsYou can use these additional tools to import and export your database:SQL Server Import and Export WizardGenerate and Publish Scripts WizardBulk copy (bcp utility)The instance with the lower SQL Server edition must be created and active before using these tools.Keep in mind that these tools require more effort than native backup and restore or AWS DMS. You might experience multiple data consistency or integrity errors that must be fixed. These errors occur when moving data using these tools. Thoroughly test the process in a test environment before deciding to use one of these tools.SQL Server Import and Export Wizard: Copy and create the schema of the source instance's databases and object on to the target instance. Then, use this wizard to copy one or more tables, views, or queries from one RDS for SQL Server DB instance to another data store. For more information, see SQL Server Import and Export Wizard.SQL Server Generate and Publish Scripts Wizard and bcp utility: Use the SQL Server Generate and Publish Scripts Wizard to create scripts for an entire database or selected objects. You can run these scripts on a target SQL Server DB instance to recreate the scripted objects. Then, use the bcp utility to bulk export the data for the selected objects to the target DB instance. Run the bcp utility from an Amazon Elastic Compute Cloud (Amazon EC2) instance that has connectivity to both the source and target RDS instances. For more information, see SQL Server Generate and Publish Scripts Wizard and bcp utility.Note: All the options mentioned in this section can also be used to migrate databases from lower edition to higher edition RDS for SQL Server instances. However, the approach explained in the Upgrade SQL Server edition section is easier. Deciding which option to use depends on factors such as downtime, effort, complexity involved, and so on.Rename the RDS instanceThe options described for upgrading or downgrading the RDS for SQL Server edition always result in the creation of a new target RDS Instance. The new RDS instance has a different RDS DNS endpoint than the existing source RDS instance.Sometimes, updating the new RDS endpoint across applications and other services misses the connection string update in one or more of these components. When this occurs, you might run into issues after the edition change of the RDS for SQL Server instance.To avoid this, consider renaming the source and target RDS instances. Renaming makes sure that the target edition instance has the same RDS DNS endpoint as that of the original source edition instance.Doing this avoids making changes in the connection strings of the dependent applications or services after the edition change on the RDS for SQL Server instance.To rename the source and target RDS instances after changing the edition, follow these steps:This example assumes that the source RDS instance is rds-original with Enterprise edition. The target instance is rds-new with Standard edition.1.    Stop all incoming traffic (stop application) to the source instance rds-original.2.    Follow any of the preceding steps or options for upgrading or downgrading the SQL Server edition on the RDS Instance. After the edition successfully changes, there are two instances: the source instance is rds-original and the target instance is rds-new.3.    Modify the source instance to rename the DB identifier from rds-original to a different name, such as rds-original-old.4.    After the instance rds-original-old is in the Available state, rename the target instance DB Identifier from rds-new to the name of original instance, rds-original.5.    Verify that the instances are renamed to rds-original-old and rds-original and are in the Available state.6.    Make sure to keep the related RDS security groups that are attached to the new edition target RDS instance the same as the source instance. This makes sure that network connectivity from the existing applications remains the same.7.    Allow incoming traffic (start application) now to the instance rds-original that has the required SQL Server edition. No changes are required for the application connection strings , since RDS has the same DNS endpoint as source instance.8.    Perform the application testing to make sure that there is no impact after RDS instance edition change.9.    If everything works, create a final snapshot of the instance rds-original-old, and then delete this instance to save on costs.Note: It's a best practice to test activities first in a lower environment before implementing on the production environment. This gives you an estimate of how much time the changes take. Also, you can identify any issues that occur during the activity to help make implementation in the production environment smoother.Related informationAWS Prescriptive Guidance - Evaluating downgrading Microsoft SQL Server from Enterprise edition to Standard edition on AWSFollow"


Question: Why am I getting errors setting up an AWS Organizations member account as a delegated administrator for AWS Config rules?

"I followed the instructions to deploy AWS Config Rules and conformance packs using a delegated admin. However, I received an error similar to the following:"

Answer: "I followed the instructions to deploy AWS Config Rules and conformance packs using a delegated admin. However, I received an error similar to the following:An error occurred (AccessDeniedException) when calling the DeregisterDelegatedAdministrator operation: You don't have permissions to access this resource.An error occurred (InvalidInputException) when calling the RegisterDelegatedAdministrator operation: You specified an unrecognized service principal.An error occurred (ConstraintViolationException) when calling the RegisterDelegatedAdministrator operation: You have exceeded the allowed number of delegated administrators for the delegated service.ResolutionFollow these troubleshooting steps for the specific error message received.Important: Before you begin, be sure that you installed and configured the AWS Command Line Interface (AWS CLI)."An error occurred (AccessDeniedException) when calling the DeregisterDelegatedAdministrator operation: You don't have permissions to access this resource."This error means that you ran the register-delegated-administrator command from an AWS Organizations member account similar to the following:  $aws organizations register-delegated-administrator --service-principal config-multiaccountsetup.amazonaws.com --account-id member-account-IDYou can delegate an administrator only from the AWS Organizations primary account. Run the register-delegated-administrator command from the AWS Organizations primary account.  "An error occurred (InvalidInputException) when calling the RegisterDelegatedAdministrator operation: You specified an unrecognized service principal."This error can occur if your AWS Organizations organization doesn't have all features and trusted access enabled.1.    Run the enable-aws-service-access command similar to the following:$aws organizations enable-aws-service-access --service-principal=config-multiaccountsetup.amazonaws.com2.    Run the register-delegated-administrator command from the AWS Organizations primary account to delegate the member account to deploy AWS Organization conformance packs and AWS Config rules:$aws organizations register-delegated-administrator --service-principal config-multiaccountsetup.amazonaws.com --account-id member-account-ID"An error occurred (ConstraintViolationException) when calling the RegisterDelegatedAdministrator operation: You have exceeded the allowed number of delegated administrators for the delegated service."This error means that the maximum member account limit of 3 is reached for registered delegated administrators.1.    To determine which delegated administrators are registered, run the list-delegated-administrators similar to the following:$aws organizations list-delegated-administrators --service-principal=config-multiaccountsetup.amazonaws.comYou receive an output similar to the following:{    "DelegatedAdministrators": [        {            "Id": "987654321098",            "Arn": "arn:aws:organizations::123456789012:account/o-anz8bj0hfs/987654321098",            "Email": "youremailalias@example.com",            "Name": "your-account-name",            "Status": "ACTIVE",            "JoinedMethod": "CREATED",            "JoinedTimestamp": 1557432887.92,            "DelegationEnabledDate": 1590681859.773        }    ]}2.    To de-register a delegated administrator, run the deregister-delegated-administrator command:$aws organizations deregister-delegated-administrator --service-principal config-multiaccountsetup.amazonaws.com --account-id member-account-ID3.    Rerun the register-delegated-administrator command to delegate an account as an administrator:  $aws organizations register-delegated-administrator --service-principal config-multiaccountsetup.amazonaws.com --account-id member-account-IDRelated informationHow do I remove a member account from an organization in AWS Organizations when I can't sign in to the member account?How do I move accounts between organizations in AWS Organizations?Follow"


Question: How can I copy S3 objects from another AWS account?

"I want to copy Amazon Simple Storage Service (Amazon S3) objects across AWS accounts. Then, I want to make sure that the destination account owns the copied objects."

Answer: "I want to copy Amazon Simple Storage Service (Amazon S3) objects across AWS accounts. Then, I want to make sure that the destination account owns the copied objects.ResolutionImportant: Objects in S3 aren't always automatically owned by the AWS account that uploads them. When you change Object Ownership, it's a best practice to use the Bucket owner enforced setting. However, this option turns off all bucket ACLs and ACLs on any objects in your bucket.With the Bucket owner enforced setting in S3 Object Ownership, the same bucket owner automatically owns all objects in an Amazon S3 bucket. The Bucket owner enforced feature also turns off all access control lists (ACLs). This simplifies access management for data stored in Amazon S3. However, for existing buckets, an S3 object is still owned by the AWS account that uploaded it, unless you explicitly turn off the ACLs.If your existing method of sharing objects relies on using ACLs, then identify the principals that use ACLs to access objects. For more information about how to review permissions before turning off any ACLs, see Prerequisites for turning off ACLs.If you can't turn off your ACLs, then follow these steps to take ownership of objects until you can adjust your bucket policy:1.    In the source account, create an AWS Identity and Access Management (IAM) customer managed policy that grants an IAM identity (user or role) proper permissions. The IAM user must have access to retrieve objects from the source bucket and put objects back into the destination bucket. You can use an IAM policy that's similar to the following example:{  "Version": "2012-10-17",  "Statement": \[    {      "Effect": "Allow",      "Action": \[        "s3:ListBucket",        "s3:GetObject"      \],      "Resource": \[        "arn:aws:s3:::source-DOC-EXAMPLE-BUCKET",        "arn:aws:s3:::source-DOC-EXAMPLE-BUCKET/\*"      \]    },    {      "Effect": "Allow",      "Action": \[        "s3:ListBucket",        "s3:PutObject",        "s3:PutObjectAcl"      \],      "Resource": \[        "arn:aws:s3:::destination-DOC-EXAMPLE-BUCKET",        "arn:aws:s3:::destination-DOC-EXAMPLE-BUCKET/\*"      \]    }  \]}Note: This example IAM policy includes only the minimum required permissions for listing objects and copying objects across buckets in different accounts. You must customize the allowed S3 actions according to your use case. For example, if the user must copy objects that have object tags, then you must also grant permissions for s3:GetObjectTagging. If you experience an error, try performing these steps as an admin user.2.    In the source account, attach the customer managed policy to the IAM identity that you want to use to copy objects to the destination bucket.3.    In the destination account, set S3 Object Ownership on the destination bucket to bucket owner preferred. After you set S3 Object Ownership, new objects uploaded with the access control list (ACL) set to bucket-owner-full-control are automatically owned by the bucket's account.4.    In the destination account, modify the bucket policy of the destination bucket to grant the source account permissions for uploading objects. Additionally, include a condition in the bucket policy that requires object uploads to set the ACL to bucket-owner-full-control. You can use a statement that's similar to the following example:Note: Replace destination-DOC-EXAMPLE-BUCKET with the name of the destination bucket. Then, replace arn:aws:iam::222222222222:user/Jane with the Amazon Resource Name (ARN) of the IAM identity from the source account.{  "Version": "2012-10-17",  "Id": "Policy1611277539797",  "Statement": \[    {      "Sid": "Stmt1611277535086",      "Effect": "Allow",      "Principal": {        "AWS": "arn:aws:iam::222222222222:user/Jane"      },      "Action": "s3:PutObject",      "Resource": "arn:aws:s3:::destination-DOC-EXAMPLE-BUCKET/\*",      "Condition": {        "StringEquals": {          "s3:x-amz-acl": "bucket-owner-full-control"        }      }    },    {      "Sid": "Stmt1611277877767",      "Effect": "Allow",      "Principal": {        "AWS": "arn:aws:iam::222222222222:user/Jane"      },      "Action": "s3:ListBucket",      "Resource": "arn:aws:s3:::destination-DOC-EXAMPLE-BUCKET"    }  \]}This example bucket policy includes only the minimum required permissions for uploading an object with the required ACL. You must customize the allowed S3 actions according to your use case. For example, if the user must copy objects that have object tags, then you must also grant permissions for s3:GetObjectTagging5.    After you configure the IAM policy and bucket policy, the IAM identity from the source account must upload objects to the destination bucket. Make sure that the ACL is set to bucket-owner-full-control. For example, the source IAM identity must run the cp AWS CLI command with the --acl option:aws s3 cp s3://source-DOC-EXAMPLE-BUCKET/object.txt s3://destination-DOC-EXAMPLE-BUCKET/object.txt --acl bucket-owner-full-controlNote: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.When you set S3 Object Ownership to bucket owner preferred, objects that you upload with bucket-owner-full-control are owned by the destination bucket's account.Important: If your S3 bucket has default encryption with AWS Key Management Service (AWS KMS) activated, then you must also modify the AWS KMS key permissions. For instructions, see My Amazon S3 bucket has default encryption using a custom AWS KMS key. How can I allow users to download from and upload to the bucket?Related informationBucket owner granting cross-account bucket permissionsHow do I change object ownership for an Amazon S3 bucket when the objects are uploaded by other AWS accounts?Using a resource-based policy to delegate access to an Amazon S3 bucket in another accountFollow"


Question: Why am I getting 503 Slow Down errors from Amazon S3 when the requests are within the supported request rate per prefix?

"The rate of requests to a prefix in my Amazon Simple Storage Service (Amazon S3) bucket is within the supported request rates per prefix, but I'm getting 503 Slow Down errors."

Answer: "The rate of requests to a prefix in my Amazon Simple Storage Service (Amazon S3) bucket is within the supported request rates per prefix, but I'm getting 503 Slow Down errors.ResolutionAmazon S3 supports a request rate of 3,500 PUT, COPY, POST, DELETE or 5,500 GET, HEAD requests per second per prefix in a bucket. When you create a prefix, Amazon S3 doesn't automatically assign the resources for this request rate. Instead, as the request rate for a prefix gradually increases, Amazon S3 automatically scales to handle the increased request rate.When you make requests at a high request rate that's close to the rate limit, Amazon S3 returns 503 Slow Down errors. To prevent these errors, maintain the request rate and implement a retry with exponential backoff. This allows Amazon S3 time to monitor the request patterns, and scale in the backend to handle the request rate.If there's a sudden increase in the request rate for objects in a prefix, then Amazon S3 might return 503 Slow Down errors. It returns these errors as it scales in the background to handle the increased request rate. To prevent these errors, configure your application to gradually increase the request rate. Then, use an exponential backoff algorithm to retry failed requests.If you exceed supported request rates, then it's a best practice to distribute objects and requests across multiple prefixes.Note: If the preceding resolutions don't resolve the errors, then get the request IDs for the failed requests, and contact AWS Support.Follow"


Question: How do I troubleshoot Amazon ECS tasks that take a long time to stop when the container instance is set to DRAINING?

"My Amazon Elastic Container Service (Amazon ECS) task is taking a long time to move to the STOPPED state. Or, my Amazon ECS task is stuck in the RUNNING state when the container instance is set to DRAINING. How can I resolve this issue?"

Answer: "My Amazon Elastic Container Service (Amazon ECS) task is taking a long time to move to the STOPPED state. Or, my Amazon ECS task is stuck in the RUNNING state when the container instance is set to DRAINING. How can I resolve this issue?Short descriptionWhen you set an ECS instance to DRAINING, Amazon ECS does the following:Prevents new tasks from being scheduled for placement on the container instanceStops tasks on the container instance that are in the RUNNING stateYour tasks can be stuck in the RUNNING state or take a longer time to move to the STOPPED state due to issues with configuration parameters or tasks. To troubleshoot these issues, consider the following options:Confirm that your DeploymentConfiguration parameters are set correctlyConfirm that the deregistration delay value is set correctlyConfirm that the ECS_CONTAINER_STOP_TIMEOUT value is set correctlyLook for other task-related issuesResolutionConfirm that your DeploymentConfiguration parameters are set correctlyOpen the Amazon ECS console.In the navigation pane, choose Clusters, and then choose the cluster where your container instance is draining.Choose the ECS Instances tab, and then choose DRAINING in the Status section.Choose your container instance, and then find out the service for the tasks that are draining or taking a long time to drain.Choose the Services tab, select the service, and then choose Deployments.Check the values for minimumHealthyPercent and maximumPercent.Note: Service tasks on the container instance that are in the RUNNING state are stopped and replaced according to the service's deployment configuration parameters: minimumHealthyPercent and maximumPercent.Confirm that the deregistration delay value is set correctlyImportant: The following steps apply only to services using the Application Load Balancer or Network Load Balancer. If your service is using the Classic Load Balancer, check the connection draining values.Open the Amazon ECS console.In the navigation pane, choose Clusters, and then choose the cluster where your container instance is draining.Choose the Services tab, and then select the service with the stack stuck in RUNNING.Choose Target Group Name.On the Details tab, scroll down, and then select the Deregistration delay check box.Confirm that the ECS_CONTAINER_STOP_TIMEOUT value is set correctlyConnect to your container instance using SSH.Run the docker inspect ecs-agent --format '{{json .Config.Env}}' command.Check if there is a value for ECS_CONTAINER_STOP_TIMEOUT.Note: ECS_CONTAINER_STOP_TIMEOUT is an ECS container agent parameter that defines the amount of time that Amazon ECS waits before ending a container. The time duration starts counting when a task is stopped. If you don't see the ECS_CONTAINER_STOP_TIMEOUT parameter in the output after running the command in step 2, then Amazon ECS is using the default value of 30s.Look for other task-related issuesConnect to your container instance using SSH.Verify that the Docker daemon and Amazon ECS container agent are running for either your Amazon Linux 1 AMIs or Amazon Linux 2 AMIs.Check the application logs based on the log driver set by logConfiguration.Note: For example, if your tasks are using the awslogs log driver, check your Amazon CloudWatch Logs for issues.Follow"


Question: How do I use the Amazon Connect StartOutboundVoiceContact API to make outbound calls to customers?

I want to use Amazon Connect to program outbound calls to contact customers. How do I automate outbound calling using the Amazon Connect StartOutboundVoiceContact API?

Answer: "I want to use Amazon Connect to program outbound calls to contact customers. How do I automate outbound calling using the Amazon Connect StartOutboundVoiceContact API?Short descriptionYou can follow the instructions in this article to create an example setup that allows you initiate calls using the StartOutboundVoiceContact API.In this example setup, your Amazon Connect contact center calls the destination number and greets the recipient with "Hello" and the name that you specify. Then, the call disconnects automatically.For other example setups, see Automating outbound calling to customers using Amazon Connect.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.Create an outbound contact flowImportant: To create a contact flow, you must log in to your Amazon Connect instance as a user with sufficient permissions in their security profile.1.    Log in to your Amazon Connect instance using your access URL (https://alias.awsapps.com/connect/login -or- https://alias.awsapps.com/connect/login).Note: Replace alias with your instance's alias.2.    In the left navigation pane, hover over Routing, and then choose Contact flows.3.    On the Contact flows page, choose a template, or choose Create contact flow to design a contact flow from scratch.4.    In the contact flow designer, for Enter a name, enter a name for the contact flow. For example: Outbound calling.5.    Choose Save.For more information, see Create a new contact flow.Add a Play prompt blockTo configure the audio prompt that customers hear during the call, use a Play prompt contact block.1.    In the contact flow designer, expand Interact.2.    Drag and drop a Play prompt block onto the canvas.3.    Choose the Play prompt block title. The block's settings menu opens.4.    For Prompt, do the following: Choose Text to speech (Ad hoc). For Enter text, enter "Hello. This is a test call." Confirm that Interpret as is set to Text. Choose Save.For more information, see Add text-to-speech to prompts and Use Amazon Connect contact attributes.Add a Disconnect / hang up blockTo automatically end the call after the outgoing message is played, use a Disconnect / hang up contact block.1.    Choose Terminate/Transfer.2.    Drag and drop a Disconnect / hang up block onto the canvas to the right of the Play prompt block.Connect the contact blocksConnect all the connectors in your contact flow to a block in the following order:Entry point > Play prompt > Disconnect / hang upImportant: All connectors must be connected to a block before you can publish the contact flow.Save and publish the contact flow1.    Choose Save to save a draft of the flow.2.    Choose Publish to activate the flow immediately.Get your Amazon Connect instance ID and contact flow ID1.    In the contact flow designer, expand Show additional flow information.2.    Under ARN, copy the Amazon Resource Name (ARN). The contact flow ARN includes your Amazon Connect instance ID and your contact flow ID. You need these IDs to call the StartOutboundVoiceContact API.Example contact flow ARNarn:aws:connect:region:123456789012:instance/12a34b56-7890-1234-cde5-6789f0a1b2c3/contact-flow/123a45b6-c7d8-9012-34e5-6fab789c012dConfirm your IAM permissions for Amazon ConnectIf you haven't already, create and attach an AWS Identity and Access Management (AWS IAM) policy that allows you to call the connect:StartOutboundVoiceContact API.The following example JSON policy document provides the required permissions:Important: Replace the instance ARN (the "Resource" value) with your Amazon Connect instance's ARN .{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "VisualEditor0",      "Effect": "Allow",      "Action": "connect:StartOutboundVoiceContact",      "Resource": "arn:aws:connect:region:123456789012:instance/12a34b56-7890-1234-cde5-6789f0a1b2c3/contact/*"    }  ]}Call the StartOutboundVoiceContact APIRun the following command from the AWS CLI:Important: Replace awsRegion with the AWS Region of your Amazon Connect instance. Replace phoneNumber with a recipient's phone number in E.164 format. Replace contactFlowId with your contact flow ID. Replace instanceId with your Amazon Connect instance ID. Replace instancePhoneNumber with the phone number for your contact center in E.164 format. For more information, see start-outbound-voice-contact in the AWS CLI Command Reference.$ aws connect start-outbound-voice-contact --region awsRegion --destination-phone-number phoneNumber --contact-flow-id contactFlowId --instance-id instanceId --source-phone-number instancePhoneNumberThe command response returns a ContactId when the action is successful, and an error code when unsuccessful.For more information about errors that are common to the StartOutboundVoiceContact API, see the Errors section in StartOutboundVoiceContact.Related informationconnect (AWS CLI Command Reference)Create promptsSet up outbound caller IDFollow"


Question: How do I resolve the "HIVE_CURSOR_ERROR" exception when I query a table in Amazon Athena?

"When I run queries on my Amazon Athena table, I get an "HIVE_CURSOR_ERROR" exception."

Answer: "When I run queries on my Amazon Athena table, I get an "HIVE_CURSOR_ERROR" exception.ResolutionYou might get this exception under one of the following conditions:The data objects in your table location are corrupt, aren't valid, or are incorrectly compressed.The records within the table data aren't valid (example: a malformed JSON record).Common HIVE_CURSOR_ERROR exceptionsYou might get one of the following HIVE_CURSOR_ERROR exceptions when there is an issue with the underlying objects:HIVE_CURSOR_ERROR: incorrect header checkHIVE_CURSOR_ERROR: invalid block typeHIVE_CURSOR_ERROR: incorrect data checkHIVE_CURSOR_ERROR: Unexpected end of input streamHIVE_CURSOR_ERROR: invalid stored block lengthsHIVE_CURSOR_ERROR: invalid distance codeIf you recently added new objects to your Amazon Simple Storage Service (Amazon S3) table location, then be sure that these objects are valid and aren't corrupt. Download the objects, and then inspect them using an appropriate tool. For example, decompress the GZIP-compressed objects to check whether the compression is valid.If your table is partitioned, check if you are able to query individual partitions. If there are new partitions in the table, they might contain objects that aren't valid.Specific HIVE_CURSOR_ERROR exceptionsHIVE_CURSOR_ERROR: Row is not a valid JSON ObjectYou get this error when a row within the table is not a valid JSON record.To resolve this issue, do the following:Recreate the table by adding the property 'ignore.malformed.json' = 'true'.Query the new table to identify the files with malformed records by running a command similar to the following:SELECT "$path" FROM example_table WHERE example_column = NULLFor more information, see Resolve JSON errors in Amazon Athena and OpenX JSON SerDe Options.HIVE_CURSOR_ERROR: Corrupted uncompressed blockYou get this error when the objects in your table location are compressed using LZO format.To avoid getting this error with LZO-compressed data, recreate the table with the INPUTFORMAT "com.hadoop.mapred.DeprecatedLzoTextInputFormat". For example:CREATE EXTERNAL TABLE example_table (    example_column_1 STRING,    example_column_2 STRING)STORED AS INPUTFORMAT 'com.hadoop.mapred.DeprecatedLzoTextInputFormat'OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'LOCATION 's3://example_bucket/example_prefix/'You can also resolve this error by using a different compression format.HIVE_CURSOR_ERROR: Can not read value at 0 in block 0 in fileYou get this error when you have invalid Parquet objects in the S3 path. Check if your Parquet objects contain DECIMAL data types. If Parquet objects contain DECIMAL data types and were written using Spark, they might be incompatible with Hive. To check this condition, try reading the Parquet objects from a Spark job.If you can read the Parquet objects using the Spark job, then rewrite the Parquet objects with legacy mode in Spark with the following configuration:spark.sql.parquet.writeLegacyFormat = trueFor information on Spark configuration Options for Parquet, see Configuration in Spark SQL guide.HIVE_CURSOR_ERROR: org.apache.hadoop.io.ArrayWritable cannot be cast to org.apache.hadoop.io.TextYou get this error if you used an incorrect SerDe during table definition. For example, the table might be using a JSON SerDe, and the source data includes Parquet objects.To resolve this error, check the source data and confirm that the correct SerDe is used. For more information, see Supported SerDes and data formats.Related informationHow do I resolve "HIVE_CURSOR_ERROR: Row is not a valid JSON Object - JSONException: Duplicate key" when reading files from AWS Config in Athena?Troubleshooting in AthenaFollow"


Question: How do I troubleshoot issues when changing my Amazon EBS volume type?

"When I try to change my Amazon Elastic Block Store (Amazon EBS) volume type, I encounter issues. How do I troubleshoot these issues?"

Answer: "When I try to change my Amazon Elastic Block Store (Amazon EBS) volume type, I encounter issues. How do I troubleshoot these issues?Short descriptionThe following are common issues that can occur when you change your Amazon EBS volume type:The size or performance isn't within the limits of the target volume type that you're changing to.The option to change the volume type on your Amazon EBS Multi-Attach activated io1 or io2 volume is grayed out.You want to change your io1, io2, gp2, gp3, or standard volume that's also the root volume of your instance. But, you don't see the sc1 and st1 HDD-backed volume types in the dropdown list.You don't see the expected performance after changing your volume type.ResolutionThe size or performance isn't within the limits of the target volume type that you're changing toWhen you modify a volume type, the size and performance must be within the limits of the target volume type. For example, if you modify a gp3 volume that's bigger than 1024 GiB to Magnetic, then you get an error message. This error occurs because standard volumes have a maximum size of 1024 GiB. Magnetic is a previous generation volume type. It's a best practice to use a current volume type for higher performance. For more information see, Amazon EBS volume types.Also, after you increase the size of your volume, the new size is immediately available to use. However, if the volume is in the "optimizing" state, then volume performance is in between the source and target configuration specifications.The option to change the volume type on your Multi-Attach activated io1 or io2 volume is grayed outYou can't change the volume type on your Multi-Attach activated io1 or io2 volume. You can modify only the size and Provisioned IOPS for Multi-Attach activated io2 volumes. See Considerations and limitations for Multi-Attach.You don't see the sc1 and st1 HDD-backed volume types in the dropdown list for certain volume typesYou can't change the following volume types to an sc1 or st1 volume because sc1 and st1 volumes aren't supported as boot volumes:io1io2gp2gp3standardFor more information on modifying Amazon EBS volumes, see Limitations.You don't see the expected performance after changing your volume typeMake sure that your workload doesn't exceed the IOPS or throughput limits of your new volume type or instance limits. If Amazon CloudWatch doesn't show that you reached your limits, then your workload might still be micro-bursting. If your workload isn't micro-bursting and you still can't determine whether you reached your limits, then contact AWS Support to further investigate the issue.Related informationWhy is my Amazon EBS volume stuck in the Optimizing state when I modify the volume?Follow"


Question: How do I use persistent storage in Amazon EKS?

I want to use persistent storage in Amazon Elastic Kubernetes Service (Amazon EKS).

Answer: "I want to use persistent storage in Amazon Elastic Kubernetes Service (Amazon EKS).Short descriptionSet up persistent storage in Amazon EKS using either of the following options:Amazon Elastic Block Store (Amazon EBS) Container Storage Interface (CSI) driverAmazon Elastic File System (Amazon EFS) Container Storage Interface (CSI) driverTo use one of these options, complete the steps in either of the following sections:Option A: Deploy and test the Amazon EBS CSI driverOption B: Deploy and test the Amazon EFS CSI driverThe commands in this article require kubectl version 1.14 or greater. To see your version of kubectl, run the following command:kubectl version --client --shortNote: It's a best practice to make sure you install the latest version of the drivers. For more information, see in the GitHub repositories for the Amazon EBS CSI driver and Amazon EFS CSI driver.ResolutionNote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you're using the most recent version of the AWS CLI.Before you complete the steps in either section, you must:1.    Install the AWS CLI.2.    Set AWS Identity and Access Management (IAM) permissions for creating and attaching a policy to the Amazon EKS worker node role CSI Driver Role.3.    Create your Amazon EKS cluster and join your worker nodes to the cluster.Note: Run the kubectl get nodes command to verify your worker nodes are attached to your cluster.4.    Run the following command to verify that your AWS IAM OpenID Connect (OIDC) provider exists for your cluster:aws eks describe-cluster --name your_cluster_name --query "cluster.identity.oidc.issuer" --output textNote: Replace your_cluster_name with your cluster name.5.    Run the following command to verify that your IAM OIDC provider is configured:`aws iam list-open-id-connect-providers | grep <ID of the oidc provider>`;Note: Replace ID of the oidc provider with your OIDC ID. If you receive a No OpenIDConnect provider found in your account error, you must create an IAM OIDC provider.6.    Install or update eksctl.7.    Run the following command to create an IAM OIDC provider:eksctl utils associate-iam-oidc-provider --cluster my-cluster --approve Note: Replace my-cluster with your cluster name.Option A: Deploy and test the Amazon EBS CSI driverDeploy the Amazon EBS CSI driver:1.    Create an IAM trust policy file, similar to the one below:cat <<EOF > trust-policy.json{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Principal": {        "Federated": "arn:aws:iam::YOUR_AWS_ACCOUNT_ID:oidc-provider/oidc.eks.YOUR_AWS_REGION.amazonaws.com/id/<your OIDC ID>"      },      "Action": "sts:AssumeRoleWithWebIdentity",      "Condition": {        "StringEquals": {          "oidc.eks.YOUR_AWS_REGION.amazonaws.com/id/<XXXXXXXXXX45D83924220DC4815XXXXX>:aud": "sts.amazonaws.com",          "oidc.eks.YOUR_AWS_REGION.amazonaws.com/id/<XXXXXXXXXX45D83924220DC4815XXXXX>:sub": "system:serviceaccount:kube-system:ebs-csi-controller-sa"        }      }    }  ]}EOFNote: Replace YOUR_AWS_ACCOUNT_ID with your account ID. Replace YOUR_AWS_REGION with your AWS Region. Replace your OIDC ID with the output from creating your IAM OIDC provider.2.    Create an IAM role named Amazon_EBS_CSI_Driver:aws iam create-role \ --role-name AmazonEKS_EBS_CSI_Driver \ --assume-role-policy-document file://"trust-policy.json"3.    Attach the AWS managed IAM policy for the EBS CSI Driver to the IAM role you created:aws iam attach-role-policy \--policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \--role-name AmazonEKS_EBS_CSI_DriverRole4.    Deploy the Amazon EBS CSI driver:Note: You can deploy the EBS CSI driver using Kustomize, Helm, or an Amazon EKS managed add-on. In the example below, the driver is deployed using the Amazon EKS add-on feature. For more information, see the aws-ebs-csi-driver installation guide.aws eks create-addon \ --cluster-name my-cluster \ --addon-name aws-ebs-csi-driver \ --service-account-role-arn arb:aws:iam::YOUR_AWS_ACCOUNT_ID:role/AmazonEKS_EBS_CSI_DriverRoleNote: Replace my-cluster with your cluster name and YOUR_AWS_ACCOUNT_ID with your account ID.Test the Amazon EBS CSI driver:You can test your Amazon EBS CSI driver with a sample application that uses dynamic provisioning for the pods. The Amazon EBS volume is provisioned on demand.1.    Clone the aws-ebs-csi-driver repository from AWS GitHub:git clone https://github.com/kubernetes-sigs/aws-ebs-csi-driver.git2.    Change your working directory to the folder that contains the Amazon EBS driver test files:cd aws-ebs-csi-driver/examples/kubernetes/dynamic-provisioning/3.    Create the Kubernetes resources required for testing:kubectl apply -f manifests/Note: The kubectl command creates a StorageClass (from the Kubernetes website), PersistentVolumeClaim (PVC) (from the Kubernetes website), and pod. The pod references the PVC. An Amazon EBS volume is provisioned only when the pod is created.4.    Describe the ebs-sc storage class:kubectl describe storageclass ebs-sc5.    Watch the pods in the default namespace and wait for the app pod's status to change to Running. For example:kubectl get pods --watch6.    View the persistent volume created because of the pod that references the PVC:kubectl get pv7.    View information about the persistent volume:kubectl describe pv your_pv_nameNote: Replace your_pv_name with the name of the persistent volume returned from the preceding step 6. The value of the Source.VolumeHandle property in the output is the ID of the physical Amazon EBS volume created in your account.8.    Verify that the pod is writing data to the volume:kubectl exec -it app -- cat /data/out.txtNote: The command output displays the current date and time stored in the /data/out.txt file. The file includes the day, month, date, and time.Option B: Deploy and test the Amazon EFS CSI driverBefore deploying the CSI driver, create an IAM role that allows the CSI driver's service account to make calls to AWS APIs on your behalf.1.    Download the IAM policy document from GitHub:curl -o iam-policy-example.json https://raw.githubusercontent.com/kubernetes-sigs/aws-efs-csi-driver/master/docs/iam-policy-example.json2.    Create an IAM policy:aws iam create-policy \    --policy-name AmazonEKS_EFS_CSI_Driver_Policy \    --policy-document file://iam-policy-example.json3.    Run the following command to determine your cluster's OIDC provider URL:aws eks describe-cluster --name your_cluster_name --query "cluster.identity.oidc.issuer" --output textNote: In step 3, replace your_cluster_name with your cluster name.4.    Create the following IAM trust policy, and then grant the AssumeRoleWithWebIdentity action to your Kubernetes service account. For example:cat <<EOF > trust-policy.json{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Principal": {        "Federated": "arn:aws:iam::YOUR_AWS_ACCOUNT_ID:oidc-provider/oidc.eks.YOUR_AWS_REGION.amazonaws.com/id/<XXXXXXXXXX45D83924220DC4815XXXXX>"      },      "Action": "sts:AssumeRoleWithWebIdentity",      "Condition": {        "StringEquals": {          "oidc.eks.YOUR_AWS_REGION.amazonaws.com/id/<XXXXXXXXXX45D83924220DC4815XXXXX>:sub": "system:serviceaccount:kube-system:efs-csi-controller-sa"        }      }    }  ]}EOFNote: In step 4, replace YOUR_AWS_ACCOUNT_ID with your account ID. Replace YOUR_AWS_REGION with your Region. Replace XXXXXXXXXX45D83924220DC4815XXXXX with the value returned in step 3.5.    Create an IAM role:aws iam create-role \  --role-name AmazonEKS_EFS_CSI_DriverRole \  --assume-role-policy-document file://"trust-policy.json"6.    Attach your new IAM policy to the role:aws iam attach-role-policy \  --policy-arn arn:aws:iam::<AWS_ACCOUNT_ID>:policy/AmazonEKS_EFS_CSI_Driver_Policy \  --role-name AmazonEKS_EFS_CSI_DriverRole7.    Save the following contents to a file named efs-service-account.yaml.---apiVersion: v1kind: ServiceAccountmetadata:  labels:    app.kubernetes.io/name: aws-efs-csi-driver  name: efs-csi-controller-sa  namespace: kube-system  annotations:    eks.amazonaws.com/role-arn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/AmazonEKS_EFS_CSI_DriverRole8.    Create the Kubernetes service account on your cluster. The Kubernetes service account named efs-csi-controller-sa is annotated with the IAM role that you created.kubectl apply -f efs-service-account.yaml9.    Install the driver using images stored in the public Amazon ECR registry by downloading the manifest:$ kubectl kustomize "github.com/kubernetes-sigs/aws-efs-csi-driver/deploy/kubernetes/overlays/stable/?ref=release-1.5" > public-ecr-driver.yamlNote: You can install the EFS CSI Driver using Helm and a Kustomize with AWS Private or Public Registry. For more information, see the AWS EFS CSI Driver documentation.10.    Edit the file 'public-ecr-driver.yaml' and annotate 'efs-csi-controller-sa' Kubernetes service account section with the ARN of the IAM role that you created:apiVersion: v1kind: ServiceAccountmetadata:  labels:    app.kubernetes.io/name: aws-efs-csi-driver  annotations:    eks.amazonaws.com/role-arn: arn:aws:iam::<accountid>:role/AmazonEKS_EFS_CSI_DriverRole  name: efs-csi-controller-sa  namespace: kube-systemDeploy the Amazon EFS CSI driverThe Amazon EFS CSI driver allows multiple pods to write to a volume at the same time with the ReadWriteMany mode.1.    To deploy the Amazon EFS CSI driver, apply the manifest:$ kubectl apply -f public-ecr-driver.yaml2.    If your cluster contains only AWS Fargate pods (no nodes), then deploy the driver with the following command (all Regions):kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-efs-csi-driver/master/deploy/kubernetes/base/csidriver.yamlCreate an Amazon EFS File system1.    Get the VPC ID for your Amazon EKS cluster:aws eks describe-cluster --name your_cluster_name --query "cluster.resourcesVpcConfig.vpcId" --output textNote: In step 3, replace your_cluster_name with your cluster name.2.    Get the CIDR range for your VPC cluster:aws ec2 describe-vpcs --vpc-ids YOUR_VPC_ID --query "Vpcs[].CidrBlock" --output textNote: In step 4, replace the YOUR_VPC_ID with the VPC ID from the preceding step 3.3.    Create a security group that allows inbound network file system (NFS) traffic for your Amazon EFS mount points:aws ec2 create-security-group --description efs-test-sg --group-name efs-sg --vpc-id YOUR_VPC_IDNote: Replace YOUR_VPC_ID with the output from the preceding step 3. Save the GroupId for later.4.    Add an NFS inbound rule so that resources in your VPC can communicate with your Amazon EFS file system:aws ec2 authorize-security-group-ingress --group-id sg-xxx --protocol tcp --port 2049 --cidr YOUR_VPC_CIDRNote: Replace YOUR_VPC_CIDR with the output from the preceding step 4. Replace sg-xxx with the security group ID from the preceding step 5.5.    Create an Amazon EFS file system for your Amazon EKS cluster:aws efs create-file-system --creation-token eks-efsNote: Save the FileSystemId for later use.6.    To create a mount target for Amazon EFS, run the following command:aws efs create-mount-target --file-system-id FileSystemId --subnet-id SubnetID --security-group sg-xxxImportant: Be sure to run the command for all the Availability Zones with the SubnetID in the Availability Zone where your worker nodes are running. Replace FileSystemId with the output of the preceding step 7 (where you created the Amazon EFS file system). Replace sg-xxx with the output of the preceding step 5 (where you created the security group). Replace SubnetID with the subnet used by your worker nodes. To create mount targets in multiple subnets, you must run the command in step 8 separately for each subnet ID. It's a best practice to create a mount target in each Availability Zone where your worker nodes are running.Note: You can create mount targets for all the Availability Zones where worker nodes are launched. Then, all the Amazon Elastic Compute Cloud (Amazon EC2) instances in the Availability Zone with the mount target can use the file system.The Amazon EFS file system and its mount targets are now running and ready to be used by pods in the cluster.Test the Amazon EFS CSI driverYou can test the Amazon EFS CSI driver by deploying two pods that write to the same file.1.    Clone the aws-efs-csi-driver repository from AWS GitHub:git clone https://github.com/kubernetes-sigs/aws-efs-csi-driver.git2.    Change your working directory to the folder that contains the Amazon EFS CSI driver test files:cd aws-efs-csi-driver/examples/kubernetes/multiple_pods/3.    Retrieve your Amazon EFS file system ID that was created earlier:aws efs describe-file-systems --query "FileSystems[*].FileSystemId" --output textNote: If the command in step 3 returns more than one result, you can use the Amazon EFS file system ID that you saved earlier.4.    In the specs/pv.yaml file, replace the spec.csi.volumeHandle value with your Amazon EFS FileSystemId from previous steps.5.    Create the Kubernetes resources required for testing:kubectl apply -f specs/Note: The kubectl command in the preceding step 5 creates an Amazon EFS storage class, PVC, persistent volume, and two pods (app1 and app2).6.    List the persistent volumes in the default namespace, and look for a persistent volume with the default/efs-claim claim:kubectl get pv -w7.    Describe the persistent volume:kubectl describe pv efs-pv8.    Test if the two pods are writing data to the file:`kubectl exec -it app1 -- tail /data/out1.txt  kubectl exec -it app2 -- tail /data/out1.txt`bWait for about one minute. The output shows the current date written to /data/out1.txt by both pods.Related informationTroubleshooting Amazon EFSFollow"


Question: How do I install a standard Let's Encrypt SSL certificate in a Lightsail instance?

How do I install a standard SSL certificate for my website hosted in an Amazon Lightsail instance that doesn't use a Bitnami stack?

Answer: "How do I install a standard SSL certificate for my website hosted in an Amazon Lightsail instance that doesn't use a Bitnami stack?Short descriptionThe following resolution covers installing a standard Let's Encrypt SSL certificate for websites hosted in Lightsail instances that don't use a Bitnami stack. Examples of these instance blueprints include Amazon Linux 2, Ubuntu, and so on. If you have a different instance blueprint or want to install a standard certificate, see one of the following:Standard Let's Encrypt certificatesFor information installing a standard Let's Encrypt SSL certificate (not a wildcard) in a Lightsail instance with a Bitnami stack, such as WordPress, LAMP, Magento, and so on, see How do I install a standard Let's Encrypt SSL certificate in a Bitnami stack hosted on Amazon Lightsail?Wildcard Let's Encrypt certificates (for example, *.example.com)For information on installing a wildcard Let's Encrypt certificate in a Lightsail instance with a Bitnami stack, such as WordPress, Lamp, Magento, MEAN, and so on, see How do I install a wildcard Let's Encrypt SSL certificate in a Bitnami stack hosted on Amazon Lightsail?For information on installing a wildcard Let's Encrypt certificate in a Lightsail instance that doesn't use a Bitnami stack, such as Amazon Linux 2, Ubuntu, and so on, see How do I install a wildcard Let's Encrypt SSL certificate in Amazon Lightsail?ResolutionPrerequisites and limitationsThe following steps cover installing the certificate in the server. You must manually complete additional steps, such as configuring the certificate and setting up HTTPS redirection.Make sure that the domain is pointing to the Lightsail Instance either directly or through a load balancer or distribution. For the certificate verification to complete, make sure that the website URL doesn't return errors from the load balancer or distribution in the web browser.Note: This method requires the installation of the Certbot tool first. For installation instructions, see How do I install the Certbot package in my Lightsail instance for Let's Encrypt installation?1.    Stop the web service running in your instance. The following are example commands for different Linux distributions:Apache web service in Linux distributions such as Amazon Linux2, CentOS, and so onsudo service httpd stopApache web service in Linux distributions such as Ubuntu, Debian, and so onsudo service apache2 stopNGINX web servicesudo service nginx stop2.    Run the following command to install the SSL certificate. Make sure to replace example.com with your domain name.sudo certbot certonly --standalone -d example.com -d www.example.comAfter the SSL certificate generates successfully, you receive the message "Successfully received certificate". The certificate and key file locations are also provided. Save these file locations to a notepad for use in step 5.3.    Start the web service. The following are example commands for different Linux distributions:Apache web service in Linux distributions such as Amazon Linux 2, CentOS, and so onsudo service httpd startApache web service in Linux distributions such as Ubuntu, Debian, and so onsudo service apache2 startNGINX web servicesudo service nginx start4.    Set up automatic certificate renewal.If the certbot package is installed using snapd, then the renewal is configured automatically in systemd timers or cronjobs. However, because the web service must be stopped before running the Certbot command, you must automate stopping and starting web service. To set up this automation, run the following commands. The following example uses Apache2 as the web service. Replace the code and stop-start command according to your web service.sudo sh -c 'printf "#!/bin/sh\n service apache2 stop \n" > /etc/letsencrypt/renewal-hooks/pre/webservice.sh'sudo sh -c 'printf "#!/bin/sh\n service apache2 start \n" > /etc/letsencrypt/renewal-hooks/post/webservice.sh'sudo chmod 755 /etc/letsencrypt/renewal-hooks/*/webservice.shIf the Linux distribution is Amazon Linux 2 or FreeBSD, then the Certbot package isn't installed using snapd. In this case, you must configure the renewal manually by running the following command. The following example uses Apache2 as the web service. Replace the code and stop-start command according to your web service.echo "30 0,12 * * * root python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew --pre-hook 'service apache2 stop' --post-hook 'service apache2 start'" | sudo tee -a /etc/crontab > /dev/null5.     Only the certificate installation and renewal setup is complete. You still must configure your web server to use this certificate and setup HTTPS redirection. This configuration varies and depends on the web server setup that you have in your instance. Refer to the official documentation based on your web service for instructions on completing these steps.Follow"


Question: How can I manage my snapshots and create backups for my Lightsail instances using AWS CLI commands?

I want to manage my snapshots and create backups for my Amazon Lightsail instances using AWS Command Line Interface (AWS CLI) commands. How can I do this?

Answer: "I want to manage my snapshots and create backups for my Amazon Lightsail instances using AWS Command Line Interface (AWS CLI) commands. How can I do this?Short descriptionFor a list of Amazon Lightsail AWS CLI commands, see the AWS CLI Command Reference and the Amazon Lightsail API Reference.The following are scenarios for using AWS CLI commands on your Lightsail instances to manage snapshots and backups:Managing manual backups:Create manual backups for your instance.List available snapshots.Managing automatic snapshots:Verify if automatic snapshots are enabled on your instances.Enable automatic snapshots.List automatic snapshots and creating a new instance from a backup with a higher bundle size or higher Lightsail plan.Important: Keep in mind the following when using AWS CLI commands:If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.JSON is the default AWS CLI output. You can use the default, or append --output json to the commands to receive output as shown in the following examples. For more information, see Controlling command output from the AWS CLI.For general information on solving AWS CLI errors, refer to Why am I receiving errors when running AWS CLI commands?The AWS CLI output displays timestamps in Unix Epoch time. Use one of the following methods to convert the timestamp into UTC:macOS:Remove the decimal point from the timestamp and any digits to the right of the decimal point, and then run the following command:# date -r 1602175741 -uThu Oct  8 16:49:01 UTC 2020Linux:Run the following command:# date -d @1602175741.603 -uThu Oct  8 16:49:01 UTC 2020Windows:Convert the timestamp using a converter, such as epochconverter.com.ResolutionManaging manual backupsCreate a manual backup for a Lightsail instanceRun the create-instance-snapshot command to create a snapshot of the Lightsail instance.The following example creates a snapshot of the instance SnapshotTestLightsailInstance1 in the eu-west-1 Region. Replace the --instance-snapshot-name, --instance-name, and --region with the appropriate values for your request.# aws lightsail create-instance-snapshot --instance-name TestLightsailInstance1 --instance-snapshot-name SnapshotTestLightsailInstance1{    "operations": [        {            "id": "d3196be7-3dc6-4508-b335-16ce45f11c90",            "resourceName": "SnapshotTestLightsailInstance1",            "resourceType": "InstanceSnapshot",            "createdAt": 1602180831.638,            "location": {                "availabilityZone": "all",                "regionName": "eu-west-1"            },            "isTerminal": false,            "operationDetails": "TestLightsailInstance1",            "operationType": "CreateInstanceSnapshot",            "status": "Started",            "statusChangedAt": 1602180831.638        },        {            "id": "df237a33-bca9-4fc3-8f46-ea5d12606f5c",            "resourceName": "TestLightsailInstance1",            "resourceType": "Instance",            "createdAt": 1602180831.638,            "location": {                "availabilityZone": "eu-west-1a",                "regionName": "eu-west-1"            },            "isTerminal": false,            "operationDetails": "SnapshotTestLightsailInstance1",            "operationType": "CreateInstanceSnapshot",            "status": "Started",            "statusChangedAt": 1602180831.638        }    ]}List available snapshotsRun the get-instance-snapshots command to list all snapshots for your Lightsail instances. The following example shows details of snapshots available in eu-west-1. Replace the --region with the appropriate values for your request.# aws lightsail get-instance-snapshots --region eu-west-1 --query 'instanceSnapshots[].{name:name,createdAt:createdAt,resourceType:resourceType,state:state,fromInstanceName:fromInstanceName,sizeInGb:sizeInGb}' --output table-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|                                                                                GetInstanceSnapshots                                                                                |+----------------+-----------------------------------------+------------------------------------------------------------------------------------------------------------+-------------------+-----------+-------------+|    createdAt   |            fromInstanceName             |                                                   name                                                     |   resourceType    | sizeInGb  |    state    |+----------------+-----------------------------------------+------------------------------------------------------------------------------------------------------------+-------------------+-----------+-------------+|  1602180831.638|  TestLightsailInstance1                 |  SnapshotTestLightsailInstance1                                                                            |  InstanceSnapshot |  40       |  available  |+----------------+-----------------------------------------+------------------------------------------------------------------------------------------------------------+-------------------+-----------+-------------+Managing automatic snapshotsVerify if automatic snapshots are enabled on your instancesRun the following command to verify if your instance has automatic snapshots enabled and to show the defined schedule. Replace TestLightsailInstance1 with your instance name and --region with the appropriate Region.# aws lightsail get-instances --region eu-west-1  --query 'instances[].{addOns:addOns,name:name,publicIpAddress:publicIpAddress,AutoMatciSnapshotStatus:(addOns[].status),Schedule:(addOns[].snapshotTimeOfDay)}' --output text| grep -w "TestLightsailInstance1"['Enabled']     ['20:00']       [{'name': 'AutoSnapshot', 'status': 'Enabled', 'snapshotTimeOfDay': '20:00'}]   TestLightsailInstance1  3.250.xx.xxEnable automatic snapshotsRun the enable-add-on command to enable automatic snapshots for your Lightsail instances. The following example creates daily automatic snapshots set to an hourly increment in UTC (08PM UTC). Replace the --resource-name, snapshotTimeOfDay, and --region with the appropriate values for your request.# aws lightsail enable-add-on --region eu-west-1 --resource-name TestLightsailInstance1 --add-on-request addOnType=AutoSnapshot,autoSnapshotAddOnRequest={snapshotTimeOfDay=20:00}{    "operations": [        {            "id": "823bb162-9848-4897-b845-8f41c375801a",            "resourceName": "TestLightsailInstance1",            "resourceType": "Instance",            "createdAt": 1602181856.652,            "location": {                "availabilityZone": "eu-west-1",                "regionName": "eu-west-1"            },            "isTerminal": false,            "operationDetails": "EnableAddOn - AutoSnapshot",            "operationType": "EnableAddOn",            "status": "Started"        }    ]}List automatic snapshots and creating a new instance from the backup with higher bundle size or higher Lightsail plan1.FSPRun the command get-auto-snapshots to list all available automatic snapshots for your Lightsail instances or disk. The following example shows details of snapshots available for the instance TestLightsailInstance1. Replace the --resource-name and --region with the appropriate values for your request.# aws lightsail get-auto-snapshots --region eu-west-1 --resource-name TestLightsailInstance1{    "resourceName": "TestLightsailInstance1",    "resourceType": "Instance",    "autoSnapshots": [        {            "date": "2020-10-08",            "createdAt": 1602188663.0,            "status": "Success",            "fromAttachedDisks": []        }    ]}2.FSPRun the create-instances-from-snapshot command to create one or more Lightsail instances from a manual or automatic backup. The following example creates an instance in the eu-west-1 Region using a specific backup and a higher sized bundle. Replace --instance-snapshot-name, --instance-names, bundle-id, and --region with the appropriate values for your request.# aws lightsail create-instances-from-snapshot --region eu-west-1 --instance-snapshot-name SnapshotTestLightsailInstance1 --instance-names RestoredTestLightsailInstance1-New  --availability-zone eu-west-1a --bundle-id large_2_0{    "operations": [        {            "id": "09f7d1bb-90f4-48dc-b304-543499e11208",            "resourceName": "RestoredTestLightsailInstance1-New",            "resourceType": "Instance",            "createdAt": 1602182374.625,            "location": {                "availabilityZone": "eu-west-1a",                "regionName": "eu-west-1"            },            "isTerminal": false,            "operationType": "CreateInstancesFromSnapshot",            "status": "Started",            "statusChangedAt": 1602182374.625        }    ]}The following example creates a new instance based on the specified backup and a higher size bundle:# aws lightsail get-instances --region eu-west-1 --query 'instances[].{name:name,createdAt:createdAt,blueprintId:blueprintId,blueprintName:blueprintName,publicIpAddress:publicIpAddress}' --output table |grep -i RestoredTestLightsailInstance1-New|  wordpress      |  WordPress     |  1602182374.625 |  RestoredTestLightsailInstance1-New      |  34.247.xx.xx    |Related informationHow can I manage my Lightsail instance using AWS CLI commands? How can I manage static IP addresses on my Lightsail instances using AWS CLI commands? Enabling or disabling automatic snapshots for instances or disks in Amazon LightsailLightsail docsFollow"


Question: How do I minimize downtime during required Amazon RDS maintenance?

I received a maintenance notification that says one of my Amazon Relational Database Service (Amazon RDS) DB instances requires maintenance. What are some strategies that I can use to minimize downtime?

Answer: "I received a maintenance notification that says one of my Amazon Relational Database Service (Amazon RDS) DB instances requires maintenance. What are some strategies that I can use to minimize downtime?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.Occasionally, AWS performs maintenance to the hardware, operating system (OS), or database engine version for a DB instance or cluster. For more information, see Maintaining a DB instance and Upgrading a DB instance engine version.For information about pending maintenance events for your Amazon RDS DB instances, check the Events pane of the Amazon RDS console. Then, check for engine-specific maintenance events. You can run describe-pending-maintenance-actions using the AWS Command Line Interface (AWS CLI) or the Amazon RDS API for DescribeDBInstances. You can also check Amazon RDS recommendations for Pending maintenance available.Hardware maintenanceBefore 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. During hardware maintenance, Single-AZ deployments are unavailable for a few minutes. Multi-AZ deployments are unavailable for the time it takes the instance to failover (usually about 60 seconds) if the Availability Zone is affected by the maintenance. If only the secondary Availability Zone is affected, then there is no failover or downtime.OS maintenanceAfter OS maintenance is scheduled for the next maintenance window, maintenance can be postponed by adjusting your preferred maintenance window. Maintenance can also be deferred by choosing Defer Upgrade from the Actions dropdown menu. To minimize downtime, modify the Amazon RDS DB instance to a Multi-AZ deployment. For Multi-AZ deployments, OS maintenance is applied to the secondary instance first, then the instance fails over, and then the primary instance is updated. The downtime is during failover. For more information, see Maintenance for Multi-AZ deployments.DB engine maintenanceUpgrades to the database engine level require downtime. Even if your RDS DB instance uses a Multi-AZ deployment, both the primary and standby DB instances are upgraded at the same time. This causes downtime until the upgrade is complete, and the duration of the downtime varies based on the size of your DB instance. For more information, see the section for your DB engine in Upgrading a DB instance engine version.Note: If you upgrade a SQL Server DB instance in a Multi-AZ deployment, then both the primary and standby instances are upgraded. Amazon RDS performs rolling upgrades, so you have an outage only for the duration of a failover. For more information, see Multi-AZ and in-memory optimization considerations.Related informationBest practices for Amazon RDSUpgrading a read replica to reduce downtime when upgrading a MySQL databaseWhat happens to Amazon RDS and Amazon Redshift queries that are running during a maintenance window?How do I configure notifications for Amazon RDS or Amazon Redshift maintenance windows?Follow"


Question: How do I troubleshoot binary logging errors that I received when using AWS DMS with Aurora MySQL as the source?

"I have an Amazon Aurora DB instance that is running MySQL and binary logging is enabled. I'm using the Aurora DB instance as the source for an AWS Database Migration Service (AWS DMS) task, and I received an error. How do I troubleshoot and resolve this error?"

Answer: "I have an Amazon Aurora DB instance that is running MySQL and binary logging is enabled. I'm using the Aurora DB instance as the source for an AWS Database Migration Service (AWS DMS) task, and I received an error. How do I troubleshoot and resolve this error?Short descriptionYou must enable binary logging on the source Aurora MySQL-Compatible Edition DB writer instance to use change data capture (CDC) with an AWS DMS task that is either FULL LOAD AND CDC or CDC only. You must use the writer instance because read replicas aren't supported as a source for CDC operations. For more information, see the Limitations on using a MySQL database as a source for AWS DMS.If binary logging isn't enabled or you're connected to the reader instance, then you see a log entry similar to the following:Messages[SOURCE_CAPTURE ]I: System var 'log_bin' = 'OFF'[SOURCE_CAPTURE ]E: Error Code [10001] : Binary Logging must be enabled for MySQL server [1020418] (mysql_endpoint_capture.c:366)ResolutionIf you're connected to the reader instance, first identify the writer instance, and then connect to the writer instance with AWS DMS. It's a best practice to connect to the cluster endpoint because the cluster endpoint points to the current writer of the cluster at all times.Then, connect to the source Aurora cluster writer node by using the cluster endpoint to confirm that binary logging is enabled:mysql> show global variables like "log_bin";+---------------+-------+| Variable_name | Value |+---------------+-------+| log_bin       | OFF   |+---------------+-------+If the log_bin parameter is set to OFF, then check the Aurora cluster's cluster parameter group to confirm that the binlog_format parameter is set to ROW. If binlog_format isn't set to ROW, modify the parameter to enable binary logging for Aurora for MySQL.Note: This is a static parameter, so you must reboot your Aurora instance for this change to take effect.After you set the binlog_format parameter to ROW, confirm that binary logging is enabled by connecting to your Aurora instance:mysql> show global variables like "log_bin";+---------------+-------+| Variable_name | Value |+---------------+-------+| log_bin       | ON    |+---------------+-------+After you enable binary logging and confirm that you're using the cluster writer endpoint with AWS DMS, restart your task.Related informationUsing a MySQL-compatible database as a source for AWS DMSFollow"


Question: Why do I still see my Amazon S3 bucket even though I deleted it?

"I deleted my Amazon Simple Storage Service (Amazon S3) bucket. However, I can still see the bucket in the Amazon S3 console or in responses to API requests. Why is this happening?"

Answer: "I deleted my Amazon Simple Storage Service (Amazon S3) bucket. However, I can still see the bucket in the Amazon S3 console or in responses to API requests. Why is this happening?ResolutionBecause of the distributed nature of Amazon S3 and itseventual consistency model, it can take some time for changes to propagate across all AWS Regions. This is why you might temporarily see your bucket in the console, or in a response to aListBuckets API request, even after you delete the bucket.Until the bucket is completely removed by Amazon S3, you might still see the bucket, but you can't perform any other actions on the bucket.Related informationBuckets overviewDeleting a BucketFollow"


Question: How do I use IAM policy variables with federated users?

"When I use the GetFederationToken API to generate temporary credentials, the ${aws:userName} policy variable doesn't work."

Answer: "When I use the GetFederationToken API to generate temporary credentials, the ${aws:userName} policy variable doesn't work.ResolutionWhen using the GetFederationToken API, use the ${aws:userID} policy variable instead of the ${aws:userName} policy variable. This is because the variable ${aws:userName} isn't present if the principal is a federated user. For more information, see where you can use policy variables.The following JSON IAM policy provides an example where the ${aws:userName} policy variable has been replaced with the ${aws:userID} policy variable:{   "Version":"2012-10-17",   "Statement":[      {         "Sid":"AllowListingOfUserFolder",         "Action":[            "s3:ListBucket"         ],         "Effect":"Allow",         "Resource":[            "arn:aws:s3:::TESTBUCKET"         ],         "Condition":{            "StringLike":{               "s3:prefix":[                  "TESTBUCKET/${aws:userid}/*"               ]            }         }      },      {         "Sid":"AllowAllS3ActionsInUserFolder",         "Action":[            "s3:PutObject",            "s3:GetObject",            "s3:GetObjectVersion",            "s3:DeleteObject"         ],         "Effect":"Allow",         "Resource":[            "arn:aws:s3:::TESTBUCKET/${aws:userid}/*"         ]      }   ]}The value for the aws:userid variable should be "ACCOUNTNUMBER:caller-specified-name".When calling the GetFederationToken API, the Name parameter value must follow the guidelines established in GetFederationToken. For example, if you specify the friendly name Bob, the correct format is "123456789102:Bob". This names your session and allows access to the Amazon Simple Storage Service (Amazon S3) bucket with a matching prefix.Note: This example assumes that the caller-specified name (friendly name) portion of the aws:userid variable is unique. A unique friendly name prevents the scenario where another user with the same friendly name is not granted access to resources specified in the JSON policy. For more information, see Unique identifiers.Related informationPermissions for GetFederationTokenToken vending machine for identity registration - sample java web applicationIAM policy elements: variables and tagsIAM identifiersFollow"