I listed 21 concepts you should know before going to the AWS Certified Security — Specialty Certification (2020).

1. How does AWS secure the CMKs that I create?

AWS KMS is designed so that no one, including AWS employees, can retrieve your plaintext CMKs from the service. The service uses hardware security modules (HSMs) that have been validated under FIPS 140–2, or are in the process of being validated, to protect the confidentiality and integrity of your keys regardless of whether you use AWS KMS or AWS CloudHSM to create your keys or you import them into the service yourself. Your plaintext CMKs never leave the HSMs, are never written to disk and are only ever used in the volatile memory of the HSMs for the time needed to perform your requested cryptographic operation. AWS KMS keys are never transmitted outside of the AWS regions in which they were created.

Source: AWS KMS FAQ

2. Restricting Access to Amazon S3 Content by Using an Origin Access Identity

Granting Permission to an Amazon CloudFront Origin Identity

The following example bucket policy grants a CloudFront Origin Identity permission to get (list) all objects in your Amazon S3 bucket. The CloudFront Origin Identity is used to enable the CloudFront private content feature. The policy uses the Canonical User prefix, instead of AWS, to specify a Canonical User ID. You must specify the canonical user ID for your CloudFront distribution's origin access identity.

{ 
  “Version”:”2012–10–17", 
  “Id”:”PolicyForCloudFrontPrivateContent”, 
  “Statement”:[ 
    { “Sid”:” Grant a CloudFront Origin Identity access to support private content”, 
      “Effect”:”Allow”, 
      “Principal”:{“CanonicalUser”:”CloudFront Origin Identity Canonical User ID"},        
      "Action":"s3:GetObject",
      "Resource":"arn:aws:s3:::examplebucket/*"
    }
  ]
}

3. AssumeRoleWithWebIdentity

Returns a set of temporary security credentials for users who have been authenticated in a mobile or web application with a web identity provider. Example providers include Amazon Cognito, Login with Amazon, Facebook, Google, or any OpenID Connect-compatible identity provider.

4. DNS Support in Your VPC

enableDnsSupport

if this attribute is false, the Amazon-provided DNS server that resolves public DNS hostnames to IP addresses is not enabled.

5. Getting Credential Reports for Your AWS Account

You can generate and download a credential report that lists all users in your account and the status of their various credentials, including passwords, access keys, and MFA devices from IAM.

6. Working with Trusted IP Lists and Threat Lists

Trusted IP lists consist of IP addresses that you have whitelisted for secure communication with your AWS infrastructure and applications. GuardDuty does not generate findings for IP addresses on trusted IP lists.

7. abort-vault-lock and initiate-vault-lock

initiate-vault-lock

1. Installing a vault lock policy on the specified vault.
2. Setting the lock state of vault lock to InProgress state
3. Returning a lock ID, which is used to complete the vault locking process.

abort-vault-lock

If the vault lock is in the Locked state when this operation is requested, the operation returns an AccessDeniedException error. Aborting the vault locking process removes the vault lock policy from the specified vault.

8. How to Use an External ID When Granting Access to Your AWS Resources to a Third Party

AWS Document about the External ID

9. CloudTrail log file Integrity

CloudTrail log file integrity validation feature allows you to determine whether a CloudTrail log file was unchanged, deleted, or modified since CloudTrail delivered it to the specified Amazon S3 bucket.

10. Amazon Macie

Amazon Macie is an ML-powered security service that helps you prevent data loss by automatically discovering, classifying, and protecting sensitive data stored in Amazon S3.

You can use Amazon Macie to protect against security threats by continuously monitoring your data and account credentials. Amazon Macie gives you an automated and low touch way to discover and classify your business data and detect sensitive information such as personally identifiable information (PII) and credential data.

11. IAM Best Practices for Root User

1. Do not use your AWS account root user access key.
2. Enable AWS multi-factor authentication (MFA) on your AWS account root user account.
3. Don’t use your AWS account root user credentials to access AWS. Instead, create individual users for anyone who needs access to your AWS account.

12. VPC Flow Log Record Example

• An ACCEPT record for the originating ping that was allowed by both the network ACL and the security group, and therefore was allowed to reach your instance.
• A REJECT record for the response ping that the network ACL denied.

2 123456789010 eni-1235b8ca123456789 203.0.113.12 172.31.16.139 0 0 1 4 336 1432917027 1432917142 ACCEPT OK

2 123456789010 eni-1235b8ca123456789 172.31.16.139 203.0.113.12 0 0 1 4 336 1432917094 1432917142 REJECT OK

13. Control Access to the AWS Services in Single Region using IAM policies

...
"Condition":
  {
    "StringEquals": {
      "aws:RequestedRegion": "eu-central-1"
    }
  }
...

14. Amazon GuardDuty Data Sources

1. VPC Flow Logs
2. DNS Logs
3. AWS CloudTrail Events

15. IAM Access Key Rotation Using APIs

1. GenerateCredentialReport
2. GetCredentialReport
3. UpdateAccessKey

16. Adding the HTTP Security Headers in Lambda@Edge

‘use strict’; 

exports.handler = (event, context, callback) => { 
  //Get contents of response 
  const response = event.Records[0].cf.response; 
  const headers = response.headers; 
  
  //Set new headers 
  headers[‘strict-transport-security’] = [{key: ‘Strict-Transport-Security’, value: ‘max-age=63072000; includeSubdomains; preload’}];

  headers[‘content-security-policy’] = [{key: ‘Content-Security-Policy’, value: “default-src ‘none’; img-src ‘self’; script-src ‘self’; style-src ‘self’; object-src ‘none’”}]; 
  
  headers[‘x-content-type-options’] = [{key: ‘X-Content-Type-Options’, value: ‘nosniff’}]; 
  
  headers[‘x-frame-options’] = [{key: ‘X-Frame-Options’, value: ‘DENY’}]; 
  
  headers[‘x-xss-protection’] = [{key: ‘X-XSS-Protection’, value: ‘1; mode=block’}]; 
  
  headers[‘referrer-policy’] = [{key: ‘Referrer-Policy’, value: ‘same-origin’}]; 

  //Return modified response 
  callback(null, response); 

};

Source: Adding HTTP Security Headers Using Lambda@Edge and Amazon CloudFront

17. Rotating Customer Master Keys in KMS

Unsupported CMK types for Automatic key rotation

1. Asymmetric CMKs
2. CMKs in custom key stores
3. CMKs that have imported key material

18. AWS Trusted Advisor

What Trusted Advisor checks and features are available to all AWS customers?

• S3 Bucket Permissions
• Security Groups — Specific Ports Unrestricted
• IAM Use
• MFA on Root Account
• EBS Public Snapshots
• RDS Public Snapshots

How does the Trusted Advisor notification feature work?

The notification email includes the summary of saving estimates and your check status, especially highlighting changes of check status.

19. What is AWS Config?

AWS Config is a fully managed service that provides you with an AWS resource inventory, configuration history, and configuration change notifications to enable security and governance. With AWS Config you can discover existing AWS resources, export a complete inventory of your AWS resources with all configuration details, and determine how a resource was configured at any point in time. These capabilities enable compliance auditing, security analysis, resource change tracking, and troubleshooting.

20. Additional Authenticated Data in KMS

EncryptionContext provides three benefits:

1. Additional authenticated data (AAD)
2. Audit trail
3. Authorization context

Source: How to Protect the Integrity of Your Encrypted Data by Using AWS Key Management Service and EncryptionContext

21. S3 ACL

As a general rule, AWS recommends using S3 bucket policies or IAM policies for access control. S3 ACLs is a legacy access control mechanism that predates IAM. However, if you already use S3 ACLs and you find them sufficient, there is no need to change.

Source: IAM Policies and Bucket Policies and ACLs! Oh, My! (Controlling Access to S3 Resources)

Introduction to the Contact Center on the Cloud

What Contact Center as a Service (CCaaS) is?

CCaaS is the contact center that is hosted on the cloud instead of hosted on-premises.

There is a detailed article about CCaaS for your reference.

No Contact Center in the Future

I think that everyone already knows the pain points of the current contact center such as long waiting time and the inconsistent response.

The example of terrible customer experience in the call center

When the contact center is migrated from the on-premises to the cloud, we can improve the overall customer satisfaction.

In my opinion, our future should aim for “No Contact Center”. The personal assistant such as Alexa or Siri can replace the job in the contact center in the future.

Two user stories to demonstrate:

1. Build the contact center on the cloud
2. Migrate the contact center to personal assistant (Amazon Alexa)

Build better voice apps. Get more articles & interviews from voice technology experts at voicetechpodcast.com

Build the Contact Center on the Cloud

Services in the Demo

1. Amazon Connect — Contact Center on the cloud
2. Amazon Lex — Chatbot on the Contact Center
3. AWS Lambda — Serverless on the Contact Center
4. Amazon SES — Omni-Channel on the Contact Center

Demonstrate how to buy the travel insurance in the cloud contact center — Pure Chatbot, Voice by Amazon Polly

Migrate the Contact Center to Personal Assistant (Alexa)

Services in the Demo

1. Amazon Alexa— To Replace the Contact Center
2. AWS Lambda — Serverless on the Personal Assistant
3. Amazon SES — Omni-Channel on the Personal Assistant

Demonstrate how to use the personal assistant (Alexa) to replace the job in the contact center

Additional Reference

AI Powered Speech Analytics for Amazon Connect | AWS Solutions

Contact Center AI | Google Cloud

“No Contact Center” — Contact Center on the Cloud was originally published in Voice Tech Podcast on Medium, where people are continuing the conversation by highlighting and responding to this story.

I listed 35 concepts you should know before going to the AWS Certified SysOps Administrator — Associate (2019). If you do not familiar with any topics listed below, I suggest you reschedule the exam.

1. ELB Metrics — SurgeQueueLength Vs SpilloverCount

SurgeQueueLength

A count of the total number of requests that are pending submission to a registered instance.

SpilloverCount

A count of the total number of requests that were rejected due to the queue being full.

2. Burstable Performance Instance

Burstable performance instances, which are T3 and T2 instances, are designed to provide a baseline level of CPU performance with the ability to burst to a higher level when required by your workload.

It can be enabled or disabled at any time for a running or stopped instance.

3. Snowball Vs Snowball Edge

4. CloudFormation — DeletePolicy

1. preserve or (in some cases) backup a resource when its stack is deleted
2. If a resource has no DeletionPolicy attribute, AWS CloudFormation deletes the resource by default.
3. To keep a resource when its stack is deleted
4. specify Retain for that resource, to prevent deletion
5. specify Snapshot to create a snapshot before deleting the resource, if the snapshot capability is supported for e.g RDS, EC2 volume etc.
6. To keep a resource when its stack is deleted, specify Retain for that resource. You can use retain for any resource. For example, you can retain a nested stack, Amazon S3 bucket, or EC2 instance so that you can continue to use or modify those resources after you delete their stacks.
7. For resources that support snapshots, such as AWS::EC2::Volume, specify Snapshot to have AWS CloudFormation create a snapshot before deleting the resource.

{
  "AWSTemplateFormatVersion" : "2010-09-09",
  "Resources" : {
  "myS3Bucket" : {
    "Type" : "AWS::S3::Bucket",
    "DeletionPolicy" : "Retain"
   }
  }
}

5. S3 — Bucket Policy Vs ACLs Vs IAM Policies

Bucket Policy

You attach S3 bucket policies at the bucket level (i.e. you can’t attach a bucket policy to an S3 object), but the permissions specified in the bucket policy apply to all the objects in the bucket.

ACLS

As a general rule, AWS recommends using S3 bucket policies or IAM policies for access control. S3 ACLs is a legacy access control mechanism that predates IAM. However, if you already use S3 ACLs and you find them sufficient, there is no need to change.

ACLS Vs Bucket Policy

Under certain circumstances, you might find that S3 ACLs meet your needs better than IAM policies or bucket policies. If you want to manage permissions on individual objects within a bucket, S3 ACLs enable you to apply policies on the objects themselves, whereas bucket policies can only be applied at the bucket level. In addition, bucket policies are limited to 20 kb in size, so consider using S3 ACLs if you find that your bucket policy grows too large.

Sample S3 Bucket Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": ["arn:aws:iam::111122223333:user/Alice",
                "arn:aws:iam::111122223333:root"]
      },
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::my_bucket",
                   "arn:aws:s3:::my_bucket/*"]
    }
  ]
}

Sample IAM Policy

{
  "Version": "2012-10-17",
  "Statement":[{
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": ["arn:aws:s3:::my_bucket",
                 "arn:aws:s3:::my_bucket/*"]
    }
  ]
}

Note that the S3 bucket policy includes a “Principal” element, which lists the principals that bucket policy controls access for. The “Principal” element is unnecessary in an IAM policy, because the principal is by default the entity that the IAM policy is attached to.

When to use IAM policies vs. S3 policies

Use IAM policies if:

1. You need to control access to AWS services other than S3. IAM policies will be easier to manage since you can centrally manage all of your permissions in IAM, instead of spreading them between IAM and S3.
2. You have numerous S3 buckets each with different permissions requirements. IAM policies will be easier to manage since you don’t have to define a large number of S3 bucket policies and can instead rely on fewer, more detailed IAM policies.
3. You prefer to keep access control policies in the IAM environment.

Use S3 bucket policies if:

1. You want a simple way to grant cross-account access to your S3 environment, without using IAM roles.
2. Your IAM policies bump up against the size limit (up to 2 kb for users, 5 kb for groups, and 10 kb for roles). S3 supports bucket policies of up 20 kb.
3. You prefer to keep access control policies in the S3 environment.

6. Cross-Account AMI Copy

You can’t copy an AMI with an associated billingProduct code that was shared with you from another account. This includes Windows AMIs and AMIs from the AWS Marketplace. To copy a shared AMI with a billingProduct code, launch an EC2 instance in your account using the shared AMI and then create an AMI from the instance.

You can’t copy an encrypted AMI that was shared with you from another account. Instead, if the underlying snapshot and encryption key were shared with you, you can copy the snapshot while re-encrypting it with a key of your own. You own the copied snapshot, and can register it as a new AMI.

7. Loss Key for Instance Store-Backed

Amazon EC2 doesn’t keep a copy of your private key; therefore, if you lose a private key, there is no way to recover it. If you lose the private key for an instance store-backed instance, you can’t access the instance; you should terminate the instance and launch another instance using a new key pair. If you lose the private key for an EBS-backed Linux instance, you can regain access to your instance.

8. How do I troubleshoot HTTP 5xx errors from Amazon S3?

The error code 500 Internal Error indicates that Amazon S3 is unable to handle the request at that time. The error code 503 Slow Down typically indicates that the requests to the S3 bucket are very high, exceeding the request rates.

9. Getting Credential Reports for Your AWS Account

You can generate and download a credential report that lists all users in your account and the status of their various credentials, including passwords, access keys, and MFA devices. You can get a credential report from the AWS Management Console, the AWS SDKs and Command Line Tools, or the IAM API.

10. AMIs Copying

1. An identical target AMI is created, but with its own unique identifier.
2. For EBS Backed AMI, an identical but distinct root and data snapshots are created.
3. Encryption status of the snapshots are preserved. However, Launch permissions, user-defined tags, or Amazon S3 bucket permissions are not copied from the source AMI to the new AMI. After the copy operation is complete, different launch permissions, user-defined tags, and Amazon S3 bucket permissions to the new AMI.
4. AMI copy image can’t be used to create an unencrypted an AMI from an encrypted AMI.
5. AMI copy image can be used to encrypt an AMI from an unencrypted AMI.

11. Glacier Retrieval Options

Expedited

to access data in 1–5 minutes, allow you to quickly access your data when occasional urgent requests for a subset of archives are required.

Standard

archives typically become available within 3–5 hours.

Bulk

access your data in approximately 5–12 hours, Bulk retrievals allow you to cost-effectively access significant portions of your data for things like big data analytics and media transcoding.

12. To create a customer gateway

For IP Address, type the static, internet-routable IP address for your customer gateway device. If your customer gateway is behind a NAT device that’s enabled for NAT-T, use the public IP address of the NAT device.

13. Amazon Redshift, High Availability

Q: What happens to my data warehouse cluster availability and data durability if my data warehouse cluster’s Availability Zone (AZ) has an outage?

If your Amazon Redshift data warehouse cluster’s Availability Zone becomes unavailable, you will not be able to use your cluster until power and network access to the AZ are restored. Your data warehouse cluster’s data is preserved so you can start using your Amazon Redshift data warehouse as soon as the AZ becomes available again. In addition, you can also choose to restore any existing snapshots to a new AZ in the same Region. Amazon Redshift will restore your most frequently accessed data first so you can resume queries as quickly as possible.

Q: Does Amazon Redshift support Multi-AZ Deployments?

Currently, Amazon Redshift only supports Single-AZ deployments. You can run data warehouse clusters in multiple AZ’s by loading data into two Amazon Redshift data warehouse clusters in separate AZs from the same set of Amazon S3 input files. With Redshift Spectrum, you can spin up multiple clusters across AZs and access data in Amazon S3 without having to load it into your cluster. In addition, you can also restore a data warehouse cluster to a different AZ from your data warehouse cluster snapshots.

14. Identity Federation in the AWS Cloud

Federation enables you to manage access to your AWS Cloud resources centrally. With federation, you can use single sign-on (SSO) to access your AWS accounts using credentials from your corporate directory. Federation uses open standards, such as Security Assertion Markup Language 2.0 (SAML), to exchange identity and security information between an identity provider (IdP) and an application.

Security Assertion Markup Language 2.0 (SAML) is an open standard for exchanging identity and security information with applications and service providers. Applications and service providers that support SAML enable you to sign in using your corporate directory credentials, such as your user name and password from Microsoft Active Directory.

15. Web Identity Federation — Amazon Cognito

Imagine that you are creating a mobile app that accesses AWS resources, such as a game that runs on a mobile device and stores player and score information using Amazon S3 and DynamoDB.

When you write such an app, you’ll make requests to AWS services that must be signed with an AWS access key. However, we strongly recommend that you do not embed or distribute long-term AWS credentials with apps that a user downloads to a device, even in an encrypted store. Instead, build your app so that it requests temporary AWS security credentials dynamically when needed using web identity federation. The supplied temporary credentials map to an AWS role that has only the permissions needed to perform the tasks required by the mobile app.

16. EC2 Monitoring

Minimum:

1. CPUUtilization
2. NetworkIn
3. Networkout
4. DiskReadOps
5. DiskWriteOps
6. DiskReadBytes
7. DiskWriteBytes

17. What happens to my backups and DB snapshots if I delete my DB instance?

When you delete a DB instance, you can create a final DB snapshot upon deletion; if you do, you can use this DB snapshot to restore the deleted DB instance at a later date. Amazon RDS retains this final user-created DB snapshot along with all other manually created DB snapshots after the DB instance is deleted.

Automated backups are deleted when the DB instance is deleted. Only manually created DB Snapshots are retained after the DB Instance is deleted.

18. MFA Protection for Access to API Operations in the Current Account

1. If user Sofía needs to stop or terminate an Amazon EC2 instance, she calls GetSessionToken. This API operation passes the ID of the MFA device and the current TOTP that Sofía gets from her device.
2. User Sofía (or an application that Sofía is using) uses the temporary credentials provided by GetSessionToken to call the Amazon EC2 StopInstances or TerminateInstances action.

19. How do I use an MFA token to authenticate access to my AWS resources through the AWS CLI?

If you plan to interact with your resources using the AWS CLI while using an MFA device, you must create a temporary session token instead. If you are using an MFA hardware device, the ARN value is similar to GAHT12345678. If you are using a virtual MFA, the value is similar to arn:aws:iam::123456789012:mfa/user.

AWS CLI command

aws sts get-session-token --serial-number arn-of-the-mfa-device --token-code code-from-token

Output

{

  "Credentials": {

    "SecretAccessKey": "secret-access-key",

    "SessionToken": "temporary-session-token",

    "Expiration": "expiration-date-time",

    "AccessKeyId": "access-key-id"

  ;}

}

20. Why can’t I connect to an S3 bucket using a gateway VPC endpoint?

DNS settings in your VPC

DNS resolution must be enabled in your VPC

Route table settings to Amazon S3

Be sure there’s a route to Amazon S3 using the gateway VPC endpoint.

Security group outbound rules

1. The default outbound rule allows all outbound traffic. If the security group doesn’t have the default outbound rule, and instead has more restrictive rules, be sure to add one of the following outbound rules:
2. An outbound rule allowing traffic from the ID of the prefix list associated with the gateway VPC endpoint.
3. Outbound rules with Destination as the public IPs used by Amazon S3.

Network ACL rules

1. In the Inbound Rules view, be sure the rules allow inbound return traffic from Amazon S3 on ephemeral TCP ports 1024–65535.
2. In the Outbound Rules view, be sure the rules allow traffic to Amazon S3.
3. Note: By default, network ACLs allow all inbound and outbound IPv4 traffic and, if applicable, IPv6 traffic. If your network ACL rules restrict traffic, you must specify the CIDR block (IP address range) for S3.

Gateway VPC endpoint policy

Review the endpoint policy. Check if the policy blocks access to the S3 bucket or to the IAM user affected by the connectivity issues. Edit the policy to enable access for the S3 bucket or IAM user.

S3 bucket policy

Be sure the bucket policy allows access from the gateway VPC endpoint and the VPC that you want to connect. Edit the policy to enable access from the gateway VPC endpoint and VPC. Your bucket policy can restrict access only from a specific public IP address or an elastic IP address associated with an instance in an Amazon VPC. You can’t restrict access based on private IP addresses associated with instances.

IAM policy

21. CloudFormation — Prevent Delete Resource (URL Request Parameter)

1. Set the DisableRollback flag to true, when creating the stack
2. Set the OnFailure to DO_NOTHING, when creating the stack

22. EBS Volume

1. General Purpose SSD (gp2) — General — 16000 (IOPS)
2. Provisioned IOPS SSD (io1) — Large database workloads — 64000 (IOPS)
3. Throughput Optimized HDD (st1) — Big Data
4. Cold HDD (sc1) — lowest storage cost
5. SSD Instance Store — 100000 (IOPS)

23. Vulnerability and Penetration Testing

The form requires you to submit information about the instances you wish to test, identify the expected start and end dates/times of your test, and requires you to read and agree to Terms and Conditions specific to penetration testing and to the use of appropriate tools for testing. Note that the end date may not be more than 90 days from the start date.

Permission is required for all penetration tests.

24. What is Amazon EFS Encryption?

Amazon EFS offers the ability to encrypt data at rest and in transit.

Data encrypted at rest is transparently encrypted while being written, and transparently decrypted while being read, so you don’t have to modify your applications. Encryption keys are managed by the AWS Key Management Service (KMS), eliminating the need to build and maintain a secure key management infrastructure.

Data encryption in transit uses industry standard Transport Layer Security (TLS) 1.2 to encrypt data sent between your clients and EFS file systems.

When you create a new file system, you can select a key that will be used to encrypt the contents of the files that you store on the file system.

25. Granting Permission to Launch EC2 Instances with IAM Roles (PassRole Permission)

As with other IAM permissions, you can specify a wildcard (*) as the resource for the PassRole permission. For example, the following policy allows a user to associate any role whose name starts with DevTeam with the instance, such as DevTeam1 or DevTeam2.

{

  "Version": "2012-10-17",

  "Statement": [{

    "Effect":"Allow",

    "Action":["ec2:*"],

    "Resource":"*"

  },

  {

   "Effect":"Allow",

   "Action":"iam:PassRole",

   "Resource":"arn:aws:iam::123456789012:role/DevTeam*"

  }]

}

You can also use a wildcard to indicate that the permission applies to all resources–in this case, that the user is allowed to associate any role with an instance:

"Resource":"arn:aws:iam::123456789012:role/*"

26. AWS Config Vs Trust Advisor Notification

Trusted Advisor notification feature

You will be notified by weekly email when you opt in for this service, and it is totally free.

AWS Config

You can configure AWS Config to stream configuration changes and notifications to an Amazon SNS topic. When a resource is updated, you can get a notification sent to your email, so that you can view the changes.

27. Network ACL

route.state — The state of a route in the route table (active | blackhole). The blackhole state indicates that the route’s target isn’t available (for example, the specified gateway isn’t attached to the VPC, the specified NAT instance has been terminated, and so on).

Route propagation allows a virtual private gateway to automatically propagate routes to the route tables so that you don’t need to manually enter VPN routes to your route tables. You can enable or disable route propagation.

28. Aurora Reader Endpoint

You use the reader endpoint for read-only connections for your Aurora cluster. This endpoint uses a load-balancing mechanism to help your cluster handle a query-intensive workload. The reader endpoint is the endpoint that you supply to applications that do reporting or other read-only operations on the cluster.

The reader endpoint only load-balances connections to available Aurora Replicas in an Aurora DB cluster. It doesn’t load-balance individual queries. If you want to load-balance each query to distribute the read workload for a DB cluster, open a new connection to the reader endpoint for each query.

Each Aurora cluster has a single built-in reader endpoint, whose name and other attributes are managed by Aurora. You can’t create, delete, or modify this kind of endpoint.

29. Cost Allocation Tag

AWS provides two types of cost allocation tags, an AWS generated tags and user-defined tags. You must activate both types of tags separately before they can appear in Cost Explorer or on a cost allocation report.

You can’t delete or merge tags. Instead, deactivate tags so that they aren’t used in your billing reports.

Only master accounts in an organization and single accounts that are not members of an organization have access to the Cost Allocation Tags manager in the Billing console.

30. AWS Organization

master account

A master account is the AWS account you use to create your organization. From the master account, you can create other accounts in your organization, invite and manage invitations for other accounts to join your organization, and remove accounts from your organization. You can also attach policies to entities such as administrative roots, organizational units (OUs), or accounts within your organization. The master account has the role of a payer account and is responsible for paying all charges accrued by the accounts in its organization. You cannot change which account in your organization is the master account.

member account

A member account is an AWS account, other than the master account, that is part of an organization. If you are an administrator of an organization, you can create member accounts in the organization and invite existing accounts to join the organization. You also can apply policies to member accounts. A member account can belong to only one organization at a time.

Control Access

You can create Service Control Policies (SCPs) that centrally control AWS service use across multiple AWS accounts. You can specifically Allow or Deny individual AWS Services. For example, you could deny the use of Kinesis or DynamoDB to your HR group within your AWS Organization. Even if IAM in that account allows it, SCP will override it.

31. Redshift — The Connection Is Refused or Fails

Example Error:

1. “Failed to establish a connection to <endpoint>.”
2. “Could not connect to server: Connection timed out. Is the server running on host ‘<endpoint>’ and accepting TCP/IP connections on port ‘<port>’?”
3. “Connection refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.”

Generally, when you receive an error message indicating that there is a failure to establish a connection, it is an issue with permission to access the cluster. You must add an ingress rule to the cluster security group for the CIDR/IP.

32. Troubleshooting AWS CloudFormation

Delete Stack Fails

1. Some resources must be empty before they can be deleted. For example, you must delete all objects in an Amazon S3 bucket or remove all instances in an Amazon EC2 security group before you can delete the bucket or security group.
2. Ensure that you have the necessary IAM permissions to delete the resources in the stack. In addition to AWS CloudFormation permissions, you must be allowed to use the underlying services, such as Amazon S3 or Amazon EC2.
3. When stacks are in the DELETE_FAILED state because AWS CloudFormation couldn’t delete a resource, rerun the deletion with the RetainResources parameter and specify the resource that AWS CloudFormation can’t delete. AWS CloudFormation deletes the stack without deleting the retained resource. Retaining resources is useful when you can’t delete a resource, such as an S3 bucket that contains objects that you want to keep, but you still want to delete the stack.
4. You cannot delete stacks that have termination protection enabled.

Dependency Error

To resolve a dependency error, add a DependsOn attribute to resources that depend on other resources in your template. In some cases, you must explicitly declare dependencies so that AWS CloudFormation can create or delete resources in the correct order.

For example, if you create an Elastic IP and a VPC with an Internet gateway in the same stack, the Elastic IP must depend on the Internet gateway attachment.

Insufficient IAM Permissions

When you work with an AWS CloudFormation stack, you not only need permissions to use AWS CloudFormation, you must also have permission to use the underlying services that are described in your template. For example, if you’re creating an Amazon S3 bucket or starting an Amazon EC2 instance, you need permissions to Amazon S3 or Amazon EC2.

Invalid Value or Unsupported Resource Property

When you create or update an AWS CloudFormation stack, your stack can fail due to invalid input parameters, unsupported resource property names, or unsupported resource property values. For input parameters, verify that the resource exists.

For example, when you specify an Amazon EC2 key pair or VPC ID, the resource must exist in your account and in the region in which you are creating or updating your stack. You can use AWS-specific parameter types to ensure that you use valid values.

For resource property names and values, update your template to use valid names and values. For a list of all the resources and their property names, see AWS Resource and Property Types Reference.

Limit Exceeded

Verify that you didn’t reach a resource limit. For example, the default number Amazon EC2 instances that you can launch is 20. If try to create more Amazon EC2 instances than your account limit, the instance creation fails and you receive the error Status=start_failed.

Also, during an update, if a resource is replaced, AWS CloudFormation creates new resource before it deletes the old one. This replacement might put your account over the resource limit, which would cause your update to fail. You can delete excess resources or request a limit increase.

No Updates to Perform

To update an AWS CloudFormation stack, you must submit template or parameter value changes to AWS CloudFormation. However, AWS CloudFormation won’t recognize some template changes as an update, such as changes to a deletion policy, update policy, condition declaration, or output declaration. If you need to make such changes without making any other change, you can add or modify a metadata attribute for any of your resources.

Wait Condition Didn’t Receive the Required Number of Signals from an Amazon EC2 Instance

Ensure that the AMI you’re using has the AWS CloudFormation helper scripts installed. If the AMI doesn’t include the helper scripts, you can also download them to your instance.

Verify that the cfn-signal command was successfully run on the instance.

33. Amazon S3 Inventory

You can use it to audit and report on the replication and encryption status of your objects for business, compliance, and regulatory needs. You can also simplify and speed up business workflows and big data jobs using Amazon S3 inventory, which provides a scheduled alternative to the Amazon S3 synchronous List API operation.

You can configure multiple inventory lists for a bucket. You can configure what object metadata to include in the inventory, whether to list all object versions or only current versions, where to store the inventory list file output, and whether to generate the inventory on a daily or weekly basis. You can also specify that the inventory list file be encrypted.

You can query Amazon S3 inventory using standard SQL by using Amazon Athena, Amazon Redshift Spectrum, and other tools such as Presto, Apache Hive, and Apache Spark. It’s easy to use Athena to run queries on your inventory files. You can use Athena for Amazon S3 inventory queries in all Regions where Athena is available.

34. Amazon S3 Analytics

By using Amazon S3 analytics storage class analysis you can analyze storage access patterns to help you decide when to transition the right data to the right storage class. This new Amazon S3 analytics feature observes data access patterns to help you determine when to transition less frequently accessed STANDARD storage to the STANDARD_IA (IA, for infrequent access) storage class.

35. Can I use Amazon ElastiCache for Memcached with an AWS persistent data store such as Amazon RDS or Amazon DynamoDB?

Yes, Amazon ElastiCache is an ideal front-end for data stores like Amazon RDS or Amazon DynamoDB, providing a high-performance middle tier for applications with extremely high request rates and/or low latency requirements.

This story is the summary for the AWS RDS FAQ and help you to filter the useful FAQ for the examination.

Target Audience

1. AWS Certified Solutions Architect — Associate
2. AWS Certified Developer — Associate
3. AWS Certified SysOps Administrator — Associate.

Questions Highlight

Q: What does Amazon RDS manage on my behalf?

Amazon RDS manages the work involved in setting up a relational database: from provisioning the infrastructure capacity you request to installing the database software. Once your database is up and running, Amazon RDS automates common administrative tasks such as performing backups and patching the software that powers your database. With optional Multi-AZ deployments, Amazon RDS also manages synchronous data replication across Availability Zones with automatic failover.

Since Amazon RDS provides native database access, you interact with the relational database software as you normally would. This means you’re still responsible for managing the database settings that are specific to your application. You’ll need to build the relational schema that best fits your use case and are responsible for any performance tuning to optimize your database for your application’s workflow.

Q: What is a maintenance window? Will my DB instance be available during maintenance events?

The Amazon RDS maintenance window is your opportunity to control when DB instance modifications, database engine version upgrades, and software patching occurs, in the event they are requested or required. If a maintenance event is scheduled for a given week, it will be initiated during the maintenance window you identify.
Maintenance events that require Amazon RDS to take your DB instance offline are scale compute operations (which generally take only a few minutes from start-to-finish), database engine version upgrades, and required software patching. Required software patching is automatically scheduled only for patches that are security and durability related. Such patching occurs infrequently (typically once every few months) and should seldom require more than a fraction of your maintenance window.

If you do not specify a preferred weekly maintenance window when creating your DB instance, a 30 minute default value is assigned. If you wish to modify when maintenance is performed on your behalf, you can do so by modifying your DB instance in the AWS Management Console, the ModifyDBInstance API or the modify-db-instance command. Each of your DB instances can have different preferred maintenance windows, if you so choose.

Running your DB instance as a Multi-AZ deployment can further reduce the impact of a maintenance event.

Q: What should I do if my queries seem to be running slow?

For production databases we encourage you to enable Enhanced Monitoring, which provides access to over 50 CPU, memory, file system, and disk I/O metrics. You can enable these features on a per-instance basis and you can choose the granularity (all the way down to 1 second). High levels of CPU utilization can reduce query performance and in this case you may want to consider scaling your DB instance class.

If you are using RDS for MySQL or MariaDB, you can access the slow query logs for your database to determine if there are slow-running SQL queries and, if so, the performance characteristics of each. You could set the “slow_query_log” DB Parameter and query the mysql.slow_log table to review the slow-running SQL queries.

If you are using RDS for Oracle, you can use the Oracle trace file data to identify slow queries.

If you are using RDS for SQL Server, you can use the client side SQL Server traces to identify slow queries.

Database Engine Versions

Q: How do I control if and when the engine version of my DB instance is upgraded to new supported versions?

Amazon RDS strives to keep your database instance up to date by providing you newer versions of the supported database engines. After a new version of a database engine is released by the vendor or development organization, it is thoroughly tested by our database engineering team before it is made available in Amazon RDS.

We recommend that you keep your database instance upgraded to the most current minor version as it will contain the latest security and functionality fixes. Unlike major version upgrades, minor version upgrades only include database changes that are backward-compatible with previous minor versions (of the same major version) of the database engine. If a new minor version does not contain fixes that would benefit RDS customers, we may choose not to make it available in RDS. Soon after a new minor version is available in RDS, we will set it to be the preferred minor version for new DB instances.

To manually upgrade a database instance to a supported engine version, use the Modify DB Instance command on the AWS Management Console or the ModifyDBInstance API and set the DB Engine Version parameter to the desired version. By default, the upgrade will be applied or during your next maintenance window. You can also choose to upgrade immediately by selecting the Apply Immediately option in the console API.

If we determine that a new engine minor version contains significant bug fixes compared to a previously released minor version, we will schedule automatic upgrades for DB instances which have the Auto Minor Version Upgrade setting to “Yes”. These upgrades will be scheduled to occur during customer-specified maintenance windows.

We schedule them so you can plan around them, because downtime is required to upgrade a DB engine version, even for Multi-AZ instances. If you wish to turn off automatic minor version upgrades, you can do so by setting the Auto Minor Version Upgrade setting to “No”.

In the case of RDS for Oracle and RDS for SQL Server, if the upgrade to the next minor version requires a change to a different edition, then we may not schedule automatic upgrades even if you have enabled the Auto Minor Version Upgrade setting. The determination on whether to schedule automatic upgrades in such situations will be made on a case-by-case basis.
Since major version upgrades involve some compatibility risk, they will not occur automatically and must be initiated by you (except in the case of major version deprecation, see below).

Q: Can I test my DB instance with a new version before upgrading?

Yes. You can do so by creating a DB snapshot of your existing DB instance, restoring from the DB snapshot to create a new DB instance, and then initiating a version upgrade for the new DB instance. You can then experiment safely on the upgraded copy of your DB instance before deciding whether or not to upgrade your original DB instance.

Q: What happens when an RDS DB engine version is deprecated?

When a minor version of a database engine is deprecated in Amazon RDS, we will provide a three (3) month period after the announcement before beginning automatic upgrades. At the end of the this period, all instances still running the deprecated minor version will be scheduled for automatic upgrade to the latest supported minor version during their scheduled maintenance windows.

When a major version of database engine is deprecated in Amazon RDS, we will provide a minimum six (6) month period after the announcement of a deprecation for you to initiate an upgrade to a supported major version. At the end of this period, an automatic upgrade to the next major version will be applied to any instances still running the deprecated version during their scheduled maintenance windows.

Once a major or minor database engine version is no longer supported in Amazon RDS, any DB instance restored from a DB snapshot created with the unsupported version will automatically and immediately be upgraded to a currently supported version.

Hardware and Scaling

Q: How do I scale the compute resources and/or storage capacity associated with my Amazon RDS Database Instance?

You can scale the compute resources and storage capacity allocated to your DB instance with the AWS Management Console, the RDS API, or the AWS Command Line Interface. Memory and CPU resources are modified by changing your DB Instance class, and storage available is changed when you modify your storage allocation. Please note that when you modify your DB Instance class or allocated storage, your requested changes will be applied during your specified maintenance window. Alternately, you can use the “apply-immediately” flag to apply your scaling requests immediately. Bear in mind that any other pending system changes will be applied as well.

Monitor the compute and storage resource utilization of your DB instance, for no additional charge, via Amazon CloudWatch. You can access metrics such as CPU utilization, storage utilization, and network traffic by clicking the “Monitoring” tab for your DB Instance in the AWS Management Console or using the Amazon CloudWatch APIs.

Q: What is the hardware configuration for Amazon RDS storage?

Amazon RDS uses EBS volumes for database and log storage. Depending on the size of storage requested, Amazon RDS automatically stripes across multiple EBS volumes to enhance IOPS performance. For MySQL and Oracle, for an existing DB instance, you may observe some I/O capacity improvement if you scale up your storage. You can scale the storage capacity allocated to your DB Instance using the AWS Management Console, the ModifyDBInstance API, or the modify-db-instance command.

However, for SQL Server, because of the extensibility limitations of striped storage attached to a Windows Server environment, Amazon RDS does not currently support increasing storage.

Q: Will my DB instance remain available during scaling?

The storage capacity allocated to your DB Instance can be increased while maintaining DB Instance availability. However, when you decide to scale the compute resources available to your DB instance up or down, your database will be temporarily unavailable while the DB instance class is modified. This period of unavailability typically lasts only a few minutes, and will occur during the maintenance window for your DB Instance, unless you specify that the modification should be applied immediately.

Q: How do I choose among the Amazon RDS storage types?

Choose the storage type most suited for your workload.

1. High-performance OLTP workloads: Amazon RDS Provisioned IOPS (SSD) Storage
2. Database workloads with moderate I/O requirements: Amazon RDS General Purpose (SSD) Storage

Automatic Backups and Database Snapshots

Q: What is the difference between automated backups and DB Snapshots?

The automated backup feature of Amazon RDS enables point-in-time recovery of your DB instance. When automated backups are turned on for your DB Instance, Amazon RDS automatically performs a full daily snapshot of your data (during your preferred backup window) and captures transaction logs (as updates to your DB Instance are made). When you initiate a point-in-time recovery, transaction logs are applied to the most appropriate daily backup in order to restore your DB instance to the specific time you requested. Amazon RDS retains backups of a DB Instance for a limited, user-specified period of time called the retention period, which by default is 7 days but can be set to up to 35 days. You can initiate a point-in-time restore and specify any second during your retention period, up to the Latest Restorable Time.

DB Snapshots are user-initiated and enable you to back up your DB instance in a known state as frequently as you wish, and then restore to that specific state at any time. DB Snapshots can be created with the AWS Management Console, CreateDBSnapshot API, or create-db-snapshot command and are kept until you explicitly delete them.

The snapshots which Amazon RDS performs for enabling automated backups are available to you for copying (using the AWS console or the copy-db-snapshot command) or for the snapshot restore functionality. You can identify them using the “automated” Snapshot Type. In addition, you can identify the time at which the snapshot has been taken by viewing the “Snapshot Created Time” field. Alternatively, the identifier of the “automated” snapshots also contains the time (in UTC) at which the snapshot has been taken.

Please note: When you perform a restore operation to a point in time or from a DB Snapshot, a new DB Instance is created with a new endpoint (the old DB Instance can be deleted if so desired). This is done to enable you to create multiple DB Instances from a specific DB Snapshot or point in time.

Q: What is a backup window and why do I need it? Is my database available during the backup window?

The preferred backup window is the user-defined period of time during which your DB Instance is backed up. Amazon RDS uses these periodic data backups in conjunction with your transaction logs to enable you to restore your DB Instance to any second during your retention period, up to the LatestRestorableTime (typically up to the last few minutes). During the backup window, storage I/O may be briefly suspended while the backup process initializes (typically under a few seconds) and you may experience a brief period of elevated latency. There is no I/O suspension for Multi-AZ DB deployments, since the backup is taken from the standby.

Q: Where are my automated backups and DB snapshots stored and how do I manage their retention?

Amazon RDS DB snapshots and automated backups are stored in S3.

Q: What happens to my backups and DB snapshots if I delete my DB instance? (Exam)

When you delete a DB instance, you can create a final DB snapshot upon deletion; if you do, you can use this DB snapshot to restore the deleted DB instance at a later date. Amazon RDS retains this final user-created DB snapshot along with all other manually created DB snapshots after the DB instance is deleted.

Automated backups are deleted when the DB instance is deleted. Only manually created DB Snapshots are retained after the DB Instance is deleted.

Security

Q: What is a DB Subnet Group and why do I need one?

A DB Subnet Group is a collection of subnets that you may want to designate for your RDS DB Instances in a VPC. Each DB Subnet Group should have at least one subnet for every Availability Zone in a given Region. When creating a DB Instance in VPC, you will need to select a DB Subnet Group. Amazon RDS then uses that DB Subnet Group and your preferred Availability Zone to select a subnet and an IP address within that subnet. Amazon RDS creates and associates an Elastic Network Interface to your DB Instance with that IP address.

Please note that, we strongly recommend you use the DNS Name to connect to your DB Instance as the underlying IP address can change (e.g., during a failover).

For Multi-AZ deployments, defining a subnet for all Availability Zones in a Region will allow Amazon RDS to create a new standby in another Availability Zone should the need arise. You need to do this even for Single-AZ deployments, just in case you want to convert them to Multi-AZ deployments at some point.

Q: Can I change the DB Subnet Group of my DB Instance?

An existing DB Subnet Group can be updated to add more subnets, either for existing Availability Zones or for new Availability Zones added since the creation of the DB Instance. Removing subnets from an existing DB Subnet Group can cause unavailability for instances if they are running in a particular AZ that gets removed from the subnet group.

Q: Can I encrypt connections between my application and my DB Instance using SSL?

Yes, this option is currently supported for the MySQL, MariaDB, SQL Server, PostgreSQL, and Oracle engines.

Amazon RDS generates an SSL certificate for each DB Instance. Once an encrypted connection is established, data transferred between the DB Instance and your application will be encrypted during transfer.

While SSL offers security benefits, be aware that SSL encryption is a compute-intensive operation and will increase the latency of your database connection. SSL support within Amazon RDS is for encrypting the connection between your application and your DB Instance; it should not be relied on for authenticating the DB Instance itself.

Q: Can I encrypt data at rest on my Amazon RDS databases?

Amazon RDS supports encryption at rest for all database engines, using keys you manage using AWS Key Management Service (KMS). On a database instance running with Amazon RDS encryption, data stored at rest in the underlying storage is encrypted, as are its automated backups, read replicas, and snapshots. Encryption and decryption are handled transparently.

You can also add encryption to a previously unencrypted DB instance or DB cluster by creating a DB snapshot and then creating a copy of that snapshot and specifying a KMS encryption key. You can then restore an encrypted DB instance or DB cluster from the encrypted snapshot.

Q: I wish to perform security analysis or operational troubleshooting on my RDS deployment. Can I get a history of all RDS API calls made on my account?

Yes. AWS CloudTrail is a web service that records AWS API calls for your account and delivers log files to you. The AWS API call history produced by CloudTrail enables security analysis, resource change tracking, and compliance auditing.

Database Configuration

Q: What are DB Parameter groups? How are they helpful?

A database parameter group (DB Parameter Group) acts as a “container” for engine configuration values that can be applied to one or more DB Instances. If you create a DB Instance without specifying a DB Parameter Group, a default DB Parameter Group is used. This default group contains engine defaults and Amazon RDS system defaults optimized for the DB Instance you are running. However, if you want your DB Instance to run with your custom-specified engine configuration values, you can simply create a new DB Parameter Group, modify the desired parameters, and modify the DB Instance to use the new DB Parameter Group. Once associated, all DB Instances that use a particular DB Parameter Group get all the parameter updates to that DB Parameter Group.

Q: How can I monitor the configuration of my Amazon RDS resources?

You can use AWS Config to continuously record configurations changes to Amazon RDS DB Instances, DB Subnet Groups, DB Snapshots, DB Security Groups, and Event Subscriptions and receive notification of changes through Amazon Simple Notification Service (SNS). You can also create AWS Config Rules to evaluate whether these RDS resources have the desired configurations.

Multi-AZ Deployments

Q: What does it mean to run a DB instance as a Multi-AZ deployment?

When you create or modify your DB instance to run as a Multi-AZ deployment, Amazon RDS automatically provisions and maintains a synchronous “standby” replica in a different Availability Zone. Updates to your DB Instance are synchronously replicated across Availability Zones to the standby in order to keep both in sync and protect your latest database updates against DB instance failure. During certain types of planned maintenance, or in the unlikely event of DB instance failure or Availability Zone failure, Amazon RDS will automatically failover to the standby so that you can resume database writes and reads as soon as the standby is promoted. Since the name record for your DB instance remains the same, your application can resume database operation without the need for manual administrative intervention. With Multi-AZ deployments, replication is transparent: you do not interact directly with the standby, and it cannot be used to serve read traffic.

Q: What do “primary” and “standby” mean in the context of a Multi-AZ deployment?

When you run a DB instance as a Multi-AZ deployment, the “primary” serves database writes and reads. In addition, Amazon RDS provisions and maintains a “standby” behind the scenes, which is an up-to-date replica of the primary. The standby is “promoted” in failover scenarios. After failover, the standby becomes the primary and accepts your database operations. You do not interact directly with the standby (e.g. for read operations) at any point prior to promotion.

Q: What are the benefits of a Multi-AZ deployment?

The chief benefits of running your DB instance as a Multi-AZ deployment are enhanced database durability and availability. The increased availability and fault tolerance offered by Multi-AZ deployments make them a natural fit for production environments.

Running your DB instance as a Multi-AZ deployment safeguards your data in the unlikely event of a DB instance component failure or loss of availability in one Availability Zone. For example, if a storage volume on your primary fails, Amazon RDS automatically initiates a failover to the standby, where all of your database updates are intact. This provides additional data durability relative to standard deployments in a single AZ, where a user-initiated restore operation would be required and updates that occurred after the latest restorable time (typically within the last five minutes) would not be available.

You also benefit from enhanced database availability when running your DB instance as a Multi-AZ deployment. If an Availability Zone failure or DB instance failure occurs, your availability impact is limited to the time automatic failover takes to complete. The availability benefits of Multi-AZ also extend to planned maintenance. For example, with automated backups, I/O activity is no longer suspended on your primary during your preferred backup window, since backups are taken from the standby. In the case of patching or DB instance class scaling, these operations occur first on the standby, prior to automatic fail over. As a result, your availability impact is limited to the time required for automatic failover to complete.

Another implied benefit of running your DB instance as a Multi-AZ deployment is that DB instance failover is automatic and requires no administration. In an Amazon RDS context, this means you are not required to monitor DB instance events and initiate manual DB instance recovery (via the RestoreDBInstanceToPointInTime or RestoreDBInstanceFromSnapshot APIs) in the event of an Availability Zone failure or DB instance failure.

Q: Are there any performance implications of running my DB instance as a Multi-AZ deployments?

You may observe elevated latencies relative to a standard DB instance deployment in a single Availability Zone as a result of the synchronous data replication performed on your behalf.

Q: When running my DB instance as a Multi-AZ deployment, can I use the standby for read or write operations?

No, the standby replica cannot serve read requests. Multi-AZ deployments are designed to provide enhanced database availability and durability, rather than read scaling benefits. As such, the feature uses synchronous replication between primary and standby. Our implementation makes sure the primary and the standby are constantly in sync, but precludes using the standby for read or write operations.

Q: What happens when I convert my RDS instance from Single-AZ to Multi-AZ?

For the RDS MySQL, MariaDB, PostgreSQL and Oracle database engines, when you elect to convert your RDS instance from Single-AZ to Multi-AZ, the following happens:

1. A snapshot of your primary instance is taken
2. A new standby instance is created in a different Availability Zone, from the snapshot
3. Synchronous replication is configured between primary and standby instances

As such, there should be no downtime incurred when an instance is converted from Single-AZ to Multi-AZ.

Q: What events would cause Amazon RDS to initiate a failover to the standby replica?

1. Loss of availability in primary Availability Zone
2. Loss of network connectivity to primary
3. Compute unit failure on primary
4. Storage failure on primary

Note: When operations such as DB instance scaling or system upgrades like OS patching are initiated for Multi-AZ deployments, for enhanced availability, they are applied first on the standby prior to an automatic failover. As a result, your availability impact is limited only to the time required for automatic failover to complete. Note that Amazon RDS Multi-AZ deployments do not failover automatically in response to database operations such as long running queries, deadlocks or database corruption errors.

Q: Will I be alerted when automatic failover occurs?

Yes, Amazon RDS will emit a DB instance event to inform you that automatic failover occurred. You can click the “Events” section of the Amazon RDS Console or use the DescribeEvents API to return information about events related to your DB instance. You can also use Amazon RDS Event Notifications to be notified when specific DB events occur.

Q: What happens during Multi-AZ failover and how long does it take?

Failover is automatically handled by Amazon RDS so that you can resume database operations as quickly as possible without administrative intervention. When failing over, Amazon RDS simply flips the canonical name record (CNAME) for your DB instance to point at the standby, which is in turn promoted to become the new primary. We encourage you to follow best practices and implement database connection retry at the application layer.

Failovers, as defined by the interval between the detection of the failure on the primary and the resumption of transactions on the standby, typically complete within one to two minutes. Failover time can also be affected by whether large uncommitted transactions must be recovered; the use of adequately large instance types is recommended with Multi-AZ for best results. AWS also recommends the use of Provisioned IOPS with Multi-AZ instances, for fast, predictable, and consistent throughput performance.

Q: Can I initiate a “forced failover” for my Multi-AZ DB instance deployment?

Amazon RDS will automatically failover without user intervention under a variety of failure conditions. In addition, Amazon RDS provides an option to initiate a failover when rebooting your instance.

Q: Will my standby be in the same Region as my primary?

Yes. Your standby is automatically provisioned in a different Availability Zone of the same Region as your DB instance primary.

Q: After failover, my primary is now located in a different Availability Zone than my other AWS resources (e.g. EC2 instances). Should I be concerned about latency?

Availability Zones are engineered to provide low latency network connectivity to other Availability Zones in the same Region. In addition, you may want to consider architecting your application and other AWS resources with redundancy across multiple Availability Zones so your application will be resilient in the event of an Availability Zone failure.

Q: How do DB Snapshots and automated backups work with my Multi-AZ deployment?

You interact with automated backup and DB Snapshot functionality in the same way whether you are running a standard deployment in a Single-AZ or Multi-AZ deployment. If you are running a Multi-AZ deployment, automated backups and DB Snapshots are simply taken from the standby to avoid I/O suspension on the primary. Please note that you may experience increased I/O latency (typically lasting a few minutes) during backups for both Single-AZ and Multi-AZ deployments.

Read Replicas

Q: What does it mean to run a DB Instance as a read replica?

Read replicas make it easy to take advantage of supported engines’ built-in replication functionality to elastically scale out beyond the capacity constraints of a single DB instance for read-heavy database workloads. Once the read replica is created, database updates on the source DB instance will be replicated using a supported engine’s native, asynchronous replication. You can create multiple Read Replicas for a given source DB Instance and distribute your application’s read traffic amongst them.

Since read replicas use supported engines’ built-in replication, they are subject to its strengths and limitations. In particular, updates are applied to your read replica(s) after they occur on the source DB instance, and replication lag can vary significantly. Read replicas can be associated with Multi-AZ deployments to gain read scaling benefits in addition to the enhanced database write availability and data durability provided by Multi-AZ deployments.

Q: When would I want to consider using an Amazon RDS read replica?

Common reasons for deploying a read replica include:

1. Scaling beyond the compute or I/O capacity of a single DB instance for read-heavy database workloads. This excess read traffic can be directed to one or more read replicas.
2. Serving read traffic while the source DB instance is unavailable. If your source DB Instance cannot take I/O requests (e.g. due to I/O suspension for backups or scheduled maintenance), you can direct read traffic to your Read Replica(s). For this use case, keep in mind that the data on the Read Replica may be “stale” since the source DB Instance is unavailable.
3. Business reporting or data warehousing scenarios; you may want business reporting queries to run against a Read Replica, rather than your primary, production DB Instance.
4. You may use a read replica for disaster recovery of the source DB instance, either in the same AWS Region or in another Region.

Q: Do I need to enable automatic backups on my DB instance before I can create read replicas?

Yes. Enable automatic backups on your source DB Instance before adding read replicas, by setting the backup retention period to a value other than 0. Backups must remain enabled for read replicas to work.

Q: Can I create a read replica in an AWS Region different from that of the source DB instance?

Yes, Amazon RDS supports cross-region read replicas. The amount of time between when data is written to the source DB instance and when it is available in the read replica will depend on the network latency between the two regions.

Q: Do Amazon RDS read replicas support synchronous replication?

No. Read replicas in Amazon RDS for MySQL, MariaDB and PostgreSQL are implemented using those engines’ native asynchronous replication. Amazon Aurora uses a different, but still asynchronous, replication mechanism.

Q: Can I use a read replica to enhance database write availability or protect the data on my source DB instance against failure scenarios?

If you are looking to use replication to increase database write availability and protect recent database updates against various failure conditions, we recommend you run your DB instance as a Multi-AZ deployment. With Amazon RDS Read Replicas, which employ supported engines’ native, asynchronous replication, database writes occur on a read replica after they have already occurred on the source DB instance, and this replication “lag” can vary significantly. In contrast, the replication used by Multi-AZ deployments is synchronous, meaning that all database writes are concurrent on the primary and standby. This protects your latest database updates, since they should be available on the standby in the event a failover is required. In addition, with Multi-AZ deployments replication is fully managed. Amazon RDS automatically monitors for DB instance failure conditions or Availability Zone failure and initiates automatic failover to the standby (or to a read replica, in the case of Amazon Aurora) if an outage occurs.

Q: Can I create a read replica with a Multi-AZ DB instance deployment as its source?

Yes. Since Multi-AZ DB instances address a different need than read replicas, it makes sense to use the two in conjunction for production deployments and to associate a read replica with a Multi-AZ DB Instance deployment. The “source” Multi AZ-DB instance provides you with enhanced write availability and data durability, and the associated read replica would improve read traffic scalability.

Q: Can I configure my Amazon RDS read replicas themselves Multi-AZ?

Amazon RDS for MySQL and MariaDB allow you to enable Multi-AZ configuration on read replicas to support disaster recovery and minimize downtime from engine upgrades. Amazon RDS for PostgreSQL does not presently support this.

Q: If my read replica(s) use a Multi-AZ DB instance deployment as a source, what happens if Multi-AZ failover occurs?

In the event of a Multi-AZ failover, any associated and available read replicas will automatically resume replication once failover has completed (acquiring updates from the newly promoted primary).

Q: Can I create a read replica of another read replica?

Amazon Aurora, Amazon RDS for MySQL and MariaDB: You can create a second-tier read replica from an existing first-tier read replica. By creating a second-tier read replica, you may be able to move some of the replication load from the master database instance to a first-tier Read Replica. Please note that a second-tier Read Replica may lag further behind the master because of additional replication latency introduced as transactions are replicated from the master to the first tier replica and then to the second-tier replica.
Amazon RDS for PostgreSQL: Read Replicas of Read Replicas are not currently supported.

Q: Can my read replicas only accept database read operations?

Read replicas are designed to serve read traffic. However, there may be use cases where advanced users wish to complete Data Definition Language (DDL) SQL statements against a read replica. Examples might include adding a database index to a read replica that is used for business reporting, without adding the same index to the corresponding source DB instance.

Amazon RDS for MySQL can be configured to permit DDL SQL statements against a read replica. If you wish to enable operations other than reads for a given read replica, modify the active DB parameter group for the read replica, setting the “read_only” parameter to “0.”

Amazon RDS for PostgreSQL does not currently support the execution of DDL SQL statements against a read replica.

Q: How do I see the status of my active read replica(s)?

Amazon RDS allows you to gain visibility into how far a read replica has fallen behind its source DB instance. The number of seconds that the read replica is behind the master is published as an Amazon CloudWatch metric (“Replica Lag”) available via the AWS Management Console or Amazon CloudWatch APIs.

Enhanced Monitoring

Q: When should I use CloudWatch instead of the RDS console dashboard?

You should use CloudWatch if you want to view historical data beyond what is available on the RDS console dashboard. You can monitor your RDS instances in CloudWatch to diagnose the health of your entire AWS stack in a single location. Currently, CloudWatch supports granularities of up to 1 minute and the values will be averaged out for granularities less than that.

Q: Can I set up alarms and notifications based on specific metrics?

Yes. You can create an alarm in CloudWatch that sends a notification when the alarm changes state. The alarm watches a single metric over a time period that you specify, and performs one or more actions based on the value of the metric relative to the specified threshold over a number of time periods.

Q: How can I delete historical data?

Since Enhanced Monitoring delivers JSON payloads into a log in your CloudWatch Logs account, you can control its retention period just like any other CloudWatch Logs stream. The default retention period configured for Enhanced Monitoring in CloudWatch Logs is 30 days.

This story will help the you to understand and implement HK FPS and Common QR Code. Many sections in my story will reference the “Common QR Code Specification for Retail Payments in Hong Kong”.

Please go to the following URL to download the document first.

Common QR Code Specification for Retail Payments in Hong Kong (Merchant-Presented mode)

Mobile App to Validate the HKFPS QR Code

The developer can use the mobile app developed by HKICL to validate the QR code you generated.

iOS Version

‎Hong Kong Common QR Code

Android Version

Hong Kong Common QR Code - Apps on Google Play

Type of HK QR Code

• Static QR Code

Consumers scanned the merchant QR code with the mobile application and the payment amount will be prompted to enter.

Recommend Business: Small merchants

• Dynamic QR Code

The QR code embedded the payment amount and the consumers scanned the QR code. The transaction will be completed.

Recommend Business: Online Shop, Large merchants

You can check the section 3 for the detail in the Common QR Code Specification for Retail Payments in Hong Kong.

Sample of the QR Code

Static QR Code

We can use the online QR decoder (https://zxing.org/w/decode.jspx) to decode the QR Code and we will have the following string.

Pattern = ID Field (2 digit) + Length Field (2 digit)+ Value Field

Example: (IDField)00(LengthField)02(ValueField)01

00020101021126270012hk.com.hkicl020782419455204000053033445802HK5902NA6002HK63046674

Dynamic QR Code

00020101021226270012hk.com.hkicl02078241945520400005303344540115802HK5902NA6002HK630439B0

You can check the section 4 for the detail in the Common QR Code Specification for Retail Payments in Hong Kong.

Sample Code to Generate the Dynamic QR Code — NodeJS

Program Highlight

• The HK Common QR Code used the CRC-16-CCITT to calculate the CRC.
• How to add the additional information such as bill number, purpose of transaction and additional consumer data request, we added the bill number in the example. You can check the section 4.5 for the detail in the Common QR Code Specification for Retail Payments in Hong Kong.
• The Error Correcting-Code for the QR code should be “L” because the QR code should be displayed on the monitor.

00020101021226270012hk.com.hkicl02078241945520400005303344540115802HK5902NA6002HK6212010898756383630429f5

Checkout my Github Sample Code

chankailong/HK-FPS-QRCode-Sample

Links for your reference/Additional Reading

• Common QR Code Specification for Retail Payments in Hong Kong (Merchant-Presented Mode)

Common QR Code Specification for Retail Payments in Hong Kong (Merchant-Presented mode)

• ISO 4217

ISO 4217 Currency codes

• CRC Parameters

Common CRC parameters

• QR Code Version

Information capacity and versions of QR Code | QRcode.com | DENSO WAVE

• QR Code ECC

行動輸入的利器-QR碼

• HK FPS

HKICL | Overview

• QR Code Error Correcting Code

What is a QR code?｜Basics of 2D codes｜"Barcode Information & Tips" Reference Site for Barcode Standards and Reading Know-How | KEYENCE

Create RDS MariaDB

Select the “Only enable options eligible for RDS Free Usage Tier” to avoid additional charge.

We will connect the RDS internally and this should be the common practice.

We can leave other options as default and focus on connecting MariaDB through Lambda.

Mark the following values for the Lambda to connect.

1. Endpoint

Create RDS MySQL

Select the “Only enable options eligible for RDS Free Usage Tier” to avoid additional charge.

We will connect the RDS internally and this should be the common practice.

We can leave other options as default and focus on connecting MySQL through Lambda.

Mark the following values for the Lambda to connect.

1. Endpoint

Go to the following story to create the Lambda and API Gateway

Step 2: Create Lambda and API Gateway (Nodejs) — AWS Serverless to RDS MySQL

Create Lambda

NodeJS Code

The online editor of the lambda cannot use the “npm install” and therefore we need to write code in our computer and then upload to the lambda.

Step 1: Create package.json

npm init

The package.json for your reference.

{
  "name": "test2",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}

Step 2: Install the “mysql” library for connecting the MySQL

npm install --save mysql

Step 3: Create Database in index.js

const mysql = require('mysql');

const con = mysql.createConnection({
  host     : process.env.RDS_HOSTNAME,
  user     : process.env.RDS_USERNAME,
  password : process.env.RDS_PASSWORD,
  port     : process.env.RDS_PORT
});

exports.handler = async (event) => {
  con.query("CREATE DATABASE mysqllab", function (err, result) {
    if (err) throw err;
    console.log("Database created");
  });
  return "Database Created"
};

Step 4: Zip all the node_modules, index.js and package.json

The RDS_HOSTNAME got from the RDS details section.

Change the existing role from “AWSLambdaEdgeExecutionRole” to “AWSLambdaVPCAccessExecutionRole”

Change the RDS MySQL Security Group

You can find your security group in the MySQL details section.

“sg-fa8db185” can from the Network section in the lambda.

Create Table in the Database

Using the same Lambda to create table — MESSAGE and change the following source code to create the table in online editor.

const mysql = require('mysql');

const con = mysql.createConnection({
  host     : process.env.RDS_HOSTNAME,
  user     : process.env.RDS_USERNAME,
  password : process.env.RDS_PASSWORD,
  port     : process.env.RDS_PORT,
  database : process.env.RDS_DATABASE
});

exports.handler = async (event) => {
  const sql = "CREATE TABLE MESSAGE (message VARCHAR(255))";
  con.query(sql, function (err, result) {
    if (err) throw err;
    console.log("Table created");
  });
  return "Table Created"
};

Insert Record into Table “MESSAGE”

Change to the following source code to insert the record.

const mysql = require('mysql');

const con = mysql.createConnection({
  host     : process.env.RDS_HOSTNAME,
  user     : process.env.RDS_USERNAME,
  password : process.env.RDS_PASSWORD,
  port     : process.env.RDS_PORT,
  database : process.env.RDS_DATABASE
});

exports.handler = (event, context, callback) => {
  // allows for using callbacks as finish/error-handlers
  context.callbackWaitsForEmptyEventLoop = false;
  const sql = "INSERT INTO MESSAGE (message) VALUES ('I am MySQL')";
  con.query(sql, (err, res) => {
    if (err) {
      throw err
    }
    callback(null, '1 records inserted.');
  })
};

Query the Record

Change to the following source code to query the record.

const mysql = require('mysql');

const con = mysql.createConnection({
  host     : process.env.RDS_HOSTNAME,
  user     : process.env.RDS_USERNAME,
  password : process.env.RDS_PASSWORD,
  port     : process.env.RDS_PORT,
  database : process.env.RDS_DATABASE
});

exports.handler = (event, context, callback) => {
  // allows for using callbacks as finish/error-handlers
  context.callbackWaitsForEmptyEventLoop = false;
  const sql = "select * from MESSAGE";
  con.query(sql, function (err, result) {
    if (err) throw err;
    callback(null, result)
  });
};

Create API Gateway

You can give me the response for support if you completed the lab or ask me questions when you face any difficulty.

Review how to create RDS MySQL in the AWS

Step 1: Create RDS MySQL — AWS Serverless to MySQL

Create API Gateway

The “Lambda function” will fill after creating Lambda.

Create Lambda

Role: Create new role from template(s)

Role name: dynamodb_read

Policy templates: Basic Lambda@Edge permissions (for CloudFront trigger)

IAM Setting

1. Go back to DynamoDB Service
2. Select your table and Get the ARN

The DynamoDB will appear on the Designer section in Lambda.

We use the Nodejs to connect the dynamoDB.

const AWS = require('aws-sdk');
AWS.config.update({ region: 'us-west-2' });
const dynamodb = new AWS.DynamoDB.DocumentClient();

exports.handler = async (event, context) => {
    return dynamodb.scan({ TableName: "dynamodb" })
    .promise()
    .then(response => response.Items)
};

Region: the location of the dynamoDB, the region code can find in the ARN.

arn:aws:dynamodb:us-west-2:5029XXXXXXXX:table/DynamoDB_Read

TableName: the table name of the dynamoDB — dynamodb

Remember to “Save”

Remember to “Add” and “Save”

You can give me the response for support if you completed the lab or ask me questions when you face any difficulty.

Check following story to review the lab.

Create DynamoDB — AWS Serverless to DynamoDB

We focuses on the lambda connecting to dynamoDB and leaves all the setting as default.

Check following story to continue the lab.

Create Lambda and API Gateway (Nodejs) — AWS Serverless to DynamoDB