AWS – IAMAWS – EC2AWS – Load BalancerAWS – Route 53AWS – RDSAWS – AuroraAWS – ElasticacheAWS – S3AWS – CloudFrontAWS – LambdaAWS – API GatewayAWS – DynamoDBAWS – KMS and EcryptionAWS – SQSAWS – SNSAWS – SESAWS – ElasticBeanstalkAWS – Elastic Container Service(ECS)AWS – KinesisAWS – CodecommitAWS – CodeBuildAWS – CloudFormationAWS – CodeDeployAWS – CLIAWS – CodePipelineAWS – CloudWatchAWS – AlexaAWS – Secrets ManagerAWS – Kubernetes on AWS
AWS – Aurora
Aurora is a fully managed relational database engine that’s compatible with MySQL and PostgreSQL. It can deliver up to five times the throughput of MySQL and up to three times the throughput of PostgreSQL without requiring changes to most of your existing applications.
When connecting to Aurora instance, it is recommended that you use a custom endpoint(endpoint that does not change) instead of the instance endpoint in such cases. Doing so simplifies connection management and high availability as you add more DB instances to your cluster.
For clusters where high availability is important, where practical use the cluster endpoint for read-write connections and the reader endpoint for read-only connections. These kinds of connections manage DB instance failover better than instance endpoints do.
DB instance types: Aurora supports two types of instance classes: Memory-Optimized and Burstable Performance.
With Aurora Serverless, you can create a database endpoint without specifying the DB instance class size. You set the minimum and maximum capacity. With Aurora Serverless, the database endpoint connects to a proxy fleet that routes the workload to a fleet of resources that are automatically scaled. Because of the proxy fleet, connections are continuous as Aurora Serverless scales the resources automatically based on the minimum and maximum capacity specifications. Database client applications don’t need to change to use the proxy fleet. Aurora Serverless manages the connections automatically. Scaling is rapid because it uses a pool of “warm” resources that are always ready to service requests. Storage and processing are separate, so you can scale down to zero processing and pay only for storage.
You can specify the minimum and maximum ACU. The minimum Aurora capacity unit is the lowest ACU to which the DB cluster can scale down. The maximum Aurora capacity unit is the highest ACU to which the DB cluster can scale up. Based on your settings, Aurora Serverless automatically creates scaling rules for thresholds for CPU utilization, connections, and available memory.
Aurora Serverless manages the warm pool of resources in an AWS Region to minimize scaling time. When Aurora Serverless adds new resources to the Aurora DB cluster, it uses the proxy fleet to switch active client connections to the new resources. At any specific time, you are only charged for the ACUs that are being actively used in your Aurora DB cluster.
- Aurora DB clusters must be created in an Amazon Virtual Private Cloud (VPC). To control which devices and Amazon EC2 instances can open connections to the endpoint and port of the DB instance for Aurora DB clusters in a VPC, you use a VPC security group. You can make these endpoint and port connections using Transport Layer Security (TLS) / Secure Sockets Layer (SSL). In addition, firewall rules at your company can control whether devices running at your company can open connections to a DB instance.
- To authenticate logins and permissions for an Amazon Aurora DB cluster, you can use the same method as MySQL.
- Configure AWS Secrets Manager to automatically rotate the secrets for Amazon Aurora.
- Rotate your IAM credentials regularly.
- Grant each user the minimum set of permissions required to perform his or her duties.
Aurora clusters across regions
- You can create an Amazon Aurora MySQL DB cluster as a Read Replica in a different AWS Region than the source DB cluster. Taking this approach can improve your disaster recovery capabilities, let you scale read operations into an AWS Region that is closer to your users, and make it easier to migrate from one AWS Region to another.
- In a cross-region scenario, there is more lag time between the source DB cluster and the Read Replica due to the longer network channels between regions.
- You can run multiple concurrent create or delete actions for Read-Replicas that reference the same source DB cluster. However, you must stay within the limit of five Read Replicas for each source DB cluster.
- For replication to operate effectively, each Read Replica should have the same amount of computing and storage resources as the source DB cluster. If you scale the source DB cluster, you should also scale the Read Replicas.
- Both your source DB cluster and your cross-region Read Replica DB cluster can have up to 15 Aurora Replicas, along with the primary instance for the DB cluster. By using this functionality, you can scale read operations for both your source AWS Region and your replication target AWS Region.
AWS – IAMAWS – EC2AWS – Load BalancerAWS – Route 53AWS – RDSAWS – AuroraAWS – ElasticacheAWS – S3AWS – CloudFrontAWS – LambdaAWS – API GatewayAWS – DynamoDBAWS – KMS and EcryptionAWS – SQSAWS – SNSAWS – SESAWS – ElasticBeanstalkAWS – Elastic Container Service(ECS)AWS – KinesisAWS – CodecommitAWS – CodeBuildAWS – CloudFormationAWS – CodeDeployAWS – CLIAWS – CodePipelineAWS – CloudWatchAWS – AlexaAWS – Secrets ManagerAWS – Kubernetes on AWS