AWS RDS

• RDS101 is relational database service.
• Relational databases are what most of us All all used. They have been around since the 70s. Think of a traditional spreadsheet.
• Worksheet is database
• Spreadsheets are tables
• We have rows and columns in tables.
• The data is organised into following entities
• Tables
• Data is organised into tables.
• Rows
• The data is organised as data items or records.
• Columns
• Fields in a database.
• Relational database is have two key features
• Multi AZ - For disaster recovery.
• DB is spread across multiple availability zones.
• If primary database is lost DNS automatically redirects to secondary database.
• Fail Over is automatic with multi AZ.
• Read Replicas - For Performance
• Whenever we write to one database it is replicated automatically to secondary database or Read Replica of Primary.
• This may be in different Availability zones.
• There is no automatic fail over to read replica once Primary databases is lost we need to create new endpoints to point to our read replica which must then be updated in our EC2 instances.
• RDS is generally used for online transactions processing(OLTP) workloads.
• Relational Database is available on Amazon are as follows
• SQL server
• Oracle
• MySql server
• Postgres SQL
• Amazon Aurora
• Maria DB
• Amazon Aurora is Amazon’s RDS service and supports Postgres and MySQL databases.
• It is multi availability zone compatible.
• It has fail over capability.
• Automated scaling.
• Nons-relational databases Have following properties
• Consist of a collection which acts like a table.
• Inside the collection we have a document which acts like a row.
• Inside document we have key-value pairs which acts like fields.
• When we add field in relational database it is added across all the records, when we add a field in non-relational database it is added only to particular record.
• Consider adding a column in a table it will have values for all the records in the table which may be Null.
• In a collection of objects one object may have a key which other object does not have.
• Data warehousing is used for business intelligence. Tools like Cognos, Jasper soft, SQL server reporting services, oracle Hyperion, SAP business warehouse.
• Used to pull in very large and complex data sets.
• Usually used by management to do queries on data such as (current performance versus targets etc).
• Data Warehousing databases use different types of architecture both from a database perspective and infrastructure layer perspective.
• Amazon’s data warehouse solution is called as Redshift.
• Red Shift also provides OLAP.
• Red Shift is used for business intelligence or data warehousing.
• OLTP Vs OLAP
• Online transaction processing OLTP differs from online analytics processing OLAP in terms of type of queries we run.
• OLTP processes, data from transactions, real-time eg customer orders, banking transactions, payments, and booking systems. OLAP possesses complex queries to analyse historical data, such as analysing net profit figures from last three years sales etc.
• OLTP is all about data processing and completing large number of small transactions in real time. OLAP is all about data analysis using large amount of data and complex queries that take long time to Complete.
• For OLTP workload, we use a database for OLAP workloads. We use a data warehouse like red shift.
• OLTP example
• Order number 21202121
• Pulls up a row of data such as name, date, address to deliver to, delivery status etc.
• OLAP example
• Net profit of Reliance and Tata for digital products.
• Pulls in large number of records Which will include following information
• Sum of digital products sold in Tata.
• Sum of digital products sold in Reliance.
• Unit cost of each digital product in each region.
• Sales price in each region
• Sales price-unit cost difference.
• Relational databases which provide online transaction processing are as follows
• SQL
• My SQL
• Postgres SQL
• Oracle
• Aurora
• Maria DB
• Dynamo DB is Amazons NoSQL solution.
• Elastic Cache is the web service that makes it easy to deploy, operate, and scale and in memory cache in the cloud. The service in improves the performance of web applications by allowing you to retrieve information from fast, managed, in memory caches instead of relying entirely on slower disk-based databases.
• Elastic Cache supports two open-source in-memory caching engines
• Mem Cached
• Redis
• Elastic Cache is Amazon’s caching solution.
• Elastic Cache to speed up performance of existing databases( cached frequent identical queries)
• Create RDS instance
• Go to RDS under databases
• Click create Database
• Select Engine type
• Select Engine version
• Select template (Free tier for testing purposes)
• Give a name to our instance
• Set up credentials
• Select DB Instance size
• Select storage
• Enable Storage autoscaling
• Set Max storage threshold.
• Select availability and durability
• Select connectivity with default VPC.
• Set up additional connectivity configuration like public accessibility etc.
• Select VPC security group.
• Set up availability zone preference.
• Set up additional configuration
• Database name
• Parameter group
• Option group
• Back up configuration
• Select maintenance window
• Select Deletion protection so that database is not deleted accidentally.
• Once set we cannot delete our database.
• Click create Database to create database
• Database may take some time to provision that is about 10 minutes.
• Create an EC2 instance and add a boot strap script that installs
• PHP
• MySQL
• Apache Server
• Installs word press from zip file.
• Since our RDS and EC2 are in different ports
• We need to allow our RDS security group to talk to EC2 security group over port 3306 i.e default port of MySQL.
• Edit RDS security group add inbound rule for MySQL over port 3306 on EC2 security group.
• Next under our RDS instance connectivity we have endpoint which will help us to connect to our DB from EC2 instance.
• Next using your public IP address install wordpress. 
• Setup the database for Wordpress using credentials set before such as dbname etc.
• Db host will be your database endpoint
• Finish remaining WordPress configuration and we are all set.
• RDS runs on virtual machine.
• You cannot log/SSH into these operating systems like we do in EC2.
• Patching of the RDS operating system and DB is Amazons responsibility.
• RDS is not serverless.
• Aurora is an exception to this rule.
• Aurora Server less is serverless.
• RDS-Backups, multi AZ and Read Replicas
• There are two different types of backups for RDS
• Automated backups
• Enabled by default. RDS creates daily back ups or snapshots that run during the back up window that you define.
• Automated backups allow you to recover your database To any point in time within a “Retention Period”
• The retention can be between one and 35 days.
• Transaction logs are used to be a replay transactions run.
• Automated back ups will take a full daily snapshot and will also store transaction logs throughout the day.
• When you do a recovery, AWS will first choose the most recent daily back up and then apply transaction logs relevant to that day.
• This allows you to do a point in time recovery down to a second within the retention period plus transaction logs.
• Automated back ups are enabled by default. The back up data is stored in S3 and you get free storage space equal to the size of your database. So if you have an RDS instance of 10 GB, you will get 10 GB worth of Storage.
• Back ups are taken with a defined window.
• During the Backup window, storage I/O may be suspended while your data is being backed up and you may experience elevated latency.
• Point in time recovery
• Recover your database at any point in time within a retention period of 1–35 days.
• Full daily backups
• RDS takes a full daily backup or snapshot and also stores transaction logs through the day.
• The recovery process
• When we do our recovery, AWS will first choose the latest, back up and then apply transaction logs relevant to that day, up to the recovery point.
• It enables point in time recovery down to a second with in the retention period.
• Stored in S3
• Automated back ups are stored in S3.
• Free storage
• We get free storage space equal to the size of your database.
• So if you have an RDS instance of 10 GB, you will get 10GB worth of storage.
• Defined back up window.
• During the backup window, storage I/O may be suspended for a few seconds while the back up process initializes, and you may experience increased latency at this time.
• Database snapshot
• Database snapshots are ad-hoc and done manually i.e. they are user initiated.
• It provides a snapshot of the storage volume attached to the database instance.
• Provides point in time snapshot only.
• They are stored even after you delete the Original RDS Instance, unlike automated back ups.
• No retention period
• Manual snapshots are not deleted even after you delete the original RDS instance, including any automated backups.
• Back up to a known state
• Back up your database instance in known state as frequently as you wish, and then restore to that specific state at any time.
• For example, before making any changes to our production database, we may want to take a DB snapshot.
• Whenever you Restore either an Automatic Backup or a manual snapshot, the restored version of the database will be a new RDS instance with new DNS endpoint.
• Includes all the underlying storage, automated backups, snapshots, logs, and read replicas.
• Encryption at rest is supported for My SQL, Oracle, SQL Server, Postgres SQL,Maria DB and Aurora.
• Enable encryption at creation, time by selecting the encryption option in the console.
• Encryption is done using the AWS Key Management Service(KMS) Service. AES-256 encryption.
• Once your RDS Instance is encrypted, the data stored at rest in the underlying storage is encrypted, as are its automated backups, Read replicas, and snapshots.
• As soon as we turn on encryption all back ups, read replicas and snapshots after that are also encrypted.
• We can’t enable encryption on an unencrypted RDS DB instance i.e. it can only be enabled at the time of creation of database.
• We can create encrypted snapshots, however, from an unencrypted database And then perform a database restore from that snapshot to get an encrypted database.
• Multi-AZ Allows you to Have and exact copy of your production Database in another availability zone. 
• AWS handles the replication for you, so when your production Database is written to, this write will automatically be synchronized to the standby database.
• In event of planned database maintenance, DB Instance failure, or any availability zone failure, Amazon RDS will automatically fail over to the standby so that database operations can resume quickly without Administrative intervention.
• Multi availability zone is for disaster recovery only
• It is not Primarily used for improving Performance.
• For performance improvement, you need read replicas.
• Multi availability zone is available for following databases
• SQL server
• Oracle
• MySql server
• Postgres SQL
• Maria DB
• We can failover from one availability zone to another by rebooting RDS instance.
• Read replicas allows you to have a read only copy of your production database. This is achieved by using Asynchronous replication  from the primary RDS Instance to the read replica.
• You use read replicas primarily for where we read heavy Database workloads.
• Read replicas are available for following the Databases.
• My SQL Server
• Postgres SQL
• Maria DB
• Oracle
• Aurora
• Read replicas are used for scaling and not for disaster recovery.
• Must have automatic back up turned on in order to deploy a read replica.
• You can have up to 5 read replica copies of any database.
• You can have read replicas of read replicas But watch out for latency.
• Each read replica will have its own DNS endpoint.
• You can have read replicas that have multi – AZ.
• You can create read replicas of multi-AZ source Databases.
• Read replicas can be promoted to be their own databases. This breaks the replication.
• You can have a replica in a second region.
• Go to RDS under Databases
• Create a new database and go to that database
• On the top right we have a drop down call as Actions next to modify where we can stop, reboot, create a Read replica,Take snapshot, migrate snapshot of database.
• Click on modify and enable multi availability zone.
• Now when we reboot we get an option reboot with failover while our dB instance is rebooting our endpoints will point to availability zone copy.
• In order to do a read replica Backup must be turned on.
• Create read replica from Actions menu 
• Set destination region.
• Set public accessibility of your read replica.
• Set to enable/disable encryption.
• Set read replica multi AZ deployment.
• Give read replica a name that is dB Instance identifier.
• click Create create read replica.
• Read Replicas
• Can be Multi AZ
• Used to increase performance.
• Must have back up turned on.
• Can be in different regions.
• Can we mySQL, Postgres SQL, Maria DB, Oracle, Aurora.
• Can Be promoted to master, this will break the read replica.
• Dynamo DB
• Amazon dynamo DB is a fast and Flexible no SQL database service for all applications that need consistent single digit millisecond latency at any scale.
• It is a fully Managed Database and supports both document and key-value Data models.
• It’s flexible data model and reliable Performance makes it a Great fit for mobile, web, gaming, ad-tech, IOT, and many other applications.
• The basics of Dynamo DB are as follows
• Stored on SSD storage. 
• Spread across three geographic distant Data center.
• Eventual consistent reads(default).
• Consistency across all copies of data is usually reached within a Second. 
• Repeating a read after a short time should return updated data.
• Strongly consistent reads.
• A strongly consistent read returns a result that reflects all writes that received a successful response prior to the read.
• So if we want to read data from dynamo DB Within one second off right we go for strongly consistent Fleets.
• This is also called as one second rule of dynamo DB.
• Stowed on SSD storage
• Spread across three geographically distant data  centers.
• Eventual consistent reads(default)
• Strongly consistent reads
• Advanced dynamo DB
• Dynamo DB Accelerator (DAX)
• Fully managed, highly available, in-memory cache.
• 10 Times performance improvement.
• Reduces request time from milliseconds to microseconds – even under load.
• No need for developers to manage caching  logic.
• Compatible with dynamo DB API calls.
• DAX sits between our application and Dynamo DB.
• DAX also has a write through cache so we also get write performance improvements.
• Dynamo DB responds to DAX writes in microseconds.
• It is also designed for higher availability zone, in event of failure of one availability zone it will fail over two it’s replica in another availability zone automatically.
• Transaction
• Multiple “all-or-nothing” operations.
• Financial transactions.
• Fulfilling orders.
• Two underlying reads or writes - prepare/commit.
• Operate on up to 25 items or 4MB of data.
• On demand capacity
• Pay-per-request pricing
• Balance cost and performance.
• No minimum capacity.
• No charge for read/write - only storage and back ups.
• Pay more per request Than the  provisioned capacity.
• Use for new product launches.
• On demand back up and restore
• Full back ups at any time
• Zero impact on table performance or availability.
• Consistent within seconds and retained until deleted.
• Operates within same region as the source table.
• Point in Time Recovery (PITR)
• Protects against accidental writes or deletes.
• Restore to any point in last 35 days.
• Incremental back ups.
• Not enabled by default.
• Latest restorable five minutes in the past.
• Streams
• Time ordered sequence of item-level changes in a table.
• Stored for 24 hours.
• Inserts, updates and deletes.
• A stream consist of stream records.
• Each stream record represents a single data modification in the Dynamo DB table to which stream belongs.
• Each stream record is assigned a sequence number reflecting the order in which the record was published in the stream.
• Stream records are organized into groups called as shards.
• A shard acts as a container for multiple stream records.
• A shard contains information required for assessing and iterating through these records.
• The stream records in shard are removed automatically after 24 hours.
• Stream use cases are as follows
• Cross region replication called as global tables.
• Establish relationships across tables using streams can we use for messaging, notification applications, aggregation or filtering, analytical reporting,Archiving, auditing and search and so on.
• Combine with lambda functions for functionality like stored procedures in traditional relational databases.
• Group Tables
• Managed multi-master, multi region Replication Solution for Dynamo DB.
• Globally distributed applications
• Based on Dynamo DB streams.
• Multi Region redundancy for disaster recovery or High Availability applications.
• No application rewrites.
• Replication latency is under one second.
• For creating global tables
• Create a Dynamo DB table.
• Add low/item to this table.
• Go to global tables tab
• Enable Dynamo DB streams
• Add a region to the global table.
• Click on create Replica.
• Your table will appear in new region.
• Add a new item to old table and we see it also replicated instantly to new availability zone.
• Database migration service (DMS)
• We can use DMS to migrate our old database to dynamo DB.
• Old database can be on premises all AWS managed Database
• We can configure all our data transformation Logic inside DMS and perform migration automatically.
• Source database remains completely operational during migration.
• Security
• Encryption at Rest is using KMS.
• Site-to-site VPN.
• Direct connect DX.
• IAM policies and roles.
• Fine grained access to certain operations.
• Cloud Watch and Cloud Trail to monitor.
• VPC endpoints
• Redshift
• Amazon red shift is a fast and powerful, fully managed, Petabyte scale data warehouse service in the cloud.
• Customers can start small for just $0.25 per hour with no commitments or up front costs and scale to a PETA byte or more for $1000 per terabyte per year, less than a 10th of most otherGetaway housing solutions.
• Red shift is a way of doing business intelligence or data warehousing in the cloud.
• Used for OLAP transactions.
• Data warehousing databases use different types of architecture both from a database perspective and infrastructure layer.
• Amazon’s Data warehouses solution is called as red shift.
• Red shift can be configured as follows
• Single node (160 GB)
• Multi node
• Leader node
• Manages client connections and receives queries.
• Compute node
• Store data and perform queries and computations.
• Up to 128 compute nodes.
• Uses advanced compression where columnar data stores can be compressed much more then row-based data stores because similar data is stored sequentially on disk.
• Amazon red shift employees multiple compression techniques and can often achieve significant compression relative to traditional relational databases.
• In addition Amazon red shift doesn’t require indexes or materialised views, and so uses less space than traditional relational database systems. When loading data to an empty table, Amazon automatically samples your data and selects the most appropriate compression scheme.
• Red shift comes with massive parallel processing (MPP)
• Amazon red shift automatically distributes data and Query load across all notes.
• Amazon red shift makes it easy to add nodes to your data warehouse and enables you to maintain fast query performance as your data warehouse grows.
• Red shift comes with backups
• Enabled by default with a one day retention period.
• Maximum retention period is 35 days.
• Red shift always attempts to maintain at least three copies of your data
• the original, the replica on the compute nodes and a back up in Amazon S3.
• Red shift can also asynchronously replicate your snapshots to S3 in another region for disaster recovery.
• Red shift is priced as follows
• Compute node hours.
• Compute node hours are total number of hours you can run across all your compute nodes, for billing period.
• You are billed for 1 unit per node  per hour, so a 3-node data warehouse cluster running persistently for an entire month would incur 2160 instance hours.
• You will not be charged for leader node hours, only compute node will incur charges.
• Back up
• Data Transfer
• Only within VPC, not outside it.
• Security considerations
• Encrypted in transit using SSL.
• Encrypted at rest using AES – 256 encryption.
• By default red shift takes care of key management
• Manage your own keys through HSMC(Hardware Security Module).
• AWS key management service.
• Red shift availability
• Currently only available in one Availability Zone.
• Can restore snapshots to new Availability Zones in the event of an outage.
• Aurora
• Amazon Aurora is a My SQL and PostgreSQL compatible relational database engine that combines the speed and availability of high end commercial Databases with the simplicity and cost effectiveness of open source databases.
• Amazon Aurora provides up to 5 times better performance than MySQL and three times better than Postgre SQL databases at a much lower price point, while delivering similar performance and availability.
• Aurora has following properties
• Starts with 10 GB, scales in 10 GB increments up to 64TB (storage autoscaling).
• Compute resources can scale up to 32 virtual CPUs and 244GB memory.
• Two copies of your data is contained in each availability zone, with minimum of three availability zones, six copies of your data.
• Scaling Aurora
• Aurora is designed 2 to transparently handle the loss of up to 2 copies of data without affecting database write availability and up to 3 copies without affecting read availability.
• Aurora storage is also self healing. Data blogs and discs continuously scanned for errors and repaired automatically.
• Three different types of Aurora’s replicas are
• Aurora Replica
• MySQL read replica
• Postgre sql

Feature	Amazon Aurora Replicas	MySQL Replicas
Number of replicas	Up to 15	Up to 5
Replication type	Asynchronous (Milliseconds)	Asynchronous (seconds)
Performance impact on primary	Low	High
Replica location	In the region	Cross region
Act As failover target	Yes (no data loss)	Yes (partially minutes of data loss)
Automated fail over	Yes	No
Support for user defined Replication delay	No	Yes
Support for Different data or schema vs Primary	No	Yes

• Backups with Aurora
• Automated backups are always enabled on Amazon Aurora DB Instances. 
• Backups do not impact Database Performance.
• You can also take snapshots with how Aurora. This also does not impact on performance.
• You can share Aurora snapshot with other AWS accounts.
• Amazon Aurora serverless is an On demand, auto scaling configuration for the MySQL compatible and Postgres SQL compatible additions of Amazon Aurora.
• An Aurora serverless DB cluster automatically starts up, shuts down, and scales capacity up or down based on your application needs.
• Aurora serverless provides relatively simple, cost-effective option four in frequent, intermittent, or unpredictable workloads.
• So for a start up website where load is undetermined we can use Aurora serverless.
• We only pay per invocations i.e when someone actually access our website.
• It is not time based like EC2 etc.
• In databases create an Aurora read replica of RDS instance
• Select DD instance class
• Select availability zone
• Give it a name
• Create a Aurora read replica
• We see we have a Aurora Cluster in our databases
• It has a reader node
• It has a writer node
• Both these nodes are in different availability zones and have different endpoints.
• We can also promote our reader node or writer node to be a read replica.
• Two copies of your data contained in each availability zone, with minimum of three availability zones, six copies of your data.
• We can share aurora snapshots with other AWS accounts.
• Three types of Replicas available Aurora replica (15),MySql Replica(5),Postgres SQL Replicas(1).Automated fail over is only available with Aurora Replicas.
• Aurora has automated backups turned on by default. You can also take snapshots with Aurora you can share these snapshots with other AWS accounts.
• Use Aurora server less if you want a simple, cost-effective, option for infrequent, intermittent or unpredictable workloads.
• Database migration service
• AWS Data Migration Service(DMS) is a cloud service that makes it easy to migrate relational Databases, data warehouses, no SQL databases, and other types of data stores.
• You can use AWS data migration service to migrate your data into the AWS cloud, between on premises instances ( through  an AWS Cloud set up), or between combinations of cloud and on premises setups.
• AWS DMS is a server in the AWS cloud that runs replication software. You can create a source and target connection to tell AWS DMS where to extract from and load to,
• Then you schedule A task that runs on the server move your data.
• AWS DMS the tables and associated Primary keys if they don’t exist on the target.
• You can pre create the target tables manually, or you can use AWS Schema Conversion Tool (SCT) to create some or all the target tables, indexes, views, triggers etc.
• Types of data migration service
• Supports homogeneous migration
• Source and destination databases are same (Oracle to Oracle).
• Supports heterogeneous migrations
• Source and Destination Databases are not same (MS SQL Server to Aurora).
• Types of sources 
• On premises and EC2 instances Databases
• Oracle, Microsoft SQL server, MySQL, Maria DB,Post Gre SQL, SAP, mongo DB, DB2.
• Azure SQL database
• Amazon RDS (including Aurora)
• Amazon S3
• Types of targets
• On premises and EC2 Instances Databases: Oracle, Microsoft SQL Server, MySQL, Maria DB, Postgre SQL, SAP.
• RDS
• Redshift
• Dynamo DB
• S3
• Elastic search service
• Kinesis data streams
• Document DB
• Implementation of DMS
• Homogeneous migration
• On premises Database transfers data to and from EC2 Instance which is running DMS which updates our RDS.
• Heterogeneous migration
• On premises database transfers Data to and from are easy to Instance running DMS & SCT schema conversion tool) Which updates our RDS.
• We do not need SCT if we are migrating two identical Databases.
• DMS allows you to migrate Databases from one source to AWS
• We can do homogeneous migration(Same DB engines)or heterogeneous migration.
• The source can either be on-premises or inside AWS itself or another Cloud provider such as as Azure.
• If you do a heterogeneous migration you will need the AWS schema conversion tool(SCT).

AWS RDS Multi AZ and Read Replicas

• AWS RDS multi availability zone
• Exact copy of your production database in another availability zone.
• AWS handles the replication for you
• When you write to your production database, this will automatically synchronise to the standby database.
• Types of RDS that can be configured as multi AZ
• SQL server
• Oracle
• My SQL
• Postgres SQL
• MARIA DB
• Main purpose of multi availability zone is to provide resilience against an unplanned failure of primary database.
• RDS will automatically fail over to the standby during and unplanned failure, so that database operations can resume quickly without administrative intervention.
• Multi availability zone is for the disaster recovery, not for scaling out or improving performance, so we cannot connect to the standby when the primary DB is active.
• Read replicas
• To improve performance. Add a read replica to your database.
• A reader replica is a read only copy of your primary database.
• Each read replica has its own DNS end points.
• It is a good option for read heavy workloads.
• A read replica can be in the same availability zone, or cross availability zone, or can be cross region.
• Read replicas can be promoted to their own data bases.
• This will break replication and will turn on read and write access on new database.
• Thus we will have two similar independent databases with read and write access.
• Used for scaling read performance.
• Primarily used for scaling not for disaster recovery.
• Requires automatic backup.
• Automatic backups must be enabled in order to deploy a read replica.
• Multiple read replicas are supported
• My SQL, Maria DB, Postgres SQL, Oracle, and SQL server, allow you to add up to 5 read replicas to each DB instance.

RDS PROXY

• Helps to increase scalability.
• Generally, application is pointed directly towards an RDS database. RDS database receives information from the application through direct connection.
• With RDS proxy our application, is pointed towards RDS proxy. RDS proxy, pools and shares database connection to assist with application, scalability and database efficiency. RDS database receives information from the application through undo RDS proxy.
• RDS proxy is fault-tolerant that is it increases application availability.
• It is server-less and scales automatically according to workload and provides connection pooling thus Sharing, The, Database connections.
• Preserve Application connections during fail over.
• Detects fail over and routes requests to standby quickly.
• Deployable over multi availability zone for protection from infrastructure failure.
• We get up to 60% foster fail over time.
• Use cases
• Applications with unpredictable workloads.
• Applications that open/close database connections in frequently.
• Applications that require availability through transient failures.
• Applications with open, but idle connections. No.

Elastic Cache

• We can speed up database queries , by storing frequently access data in memory cache.
• Memory is faster than disk.
• Elastic cache is an in memory cache which helps us to deploy, operate, and scale, and in memory cache in the cloud.
• It is designed to Improve database performance. It allows us to retrieve information from fast, in memory cache instead of slower disk-based storage.
• Great for read heavy database work loads.  Caching the results. Of input/output, intensive database queries. also for storing session data for distributed applications.
• Elastic cache is an in memory cache designed to improve, read performance for read, heavy databases .
• There are two types of elastic cache
• Memcached
• In memory, Key-value data store.
• Object caching is your primary goal.
• Great for basic object caching.
• You want to keep things as simple as possible.
• You don’t need persistence or Multi-AZ.
• You don’t need to support advanced. data types or sorting.
• Scales horizontally, but there is no persistence, Multi availability zone or failover.
• A good choice. if you want basic caching and you want you all caching model to be as simple as possible.
• Redis Cache 
• A more sophisticated solution with enterprise features, like persistence, replication , multi availability, zone, and failover.
• Supports sorting and ranking data (for gaming leaderboards), and complex data types like lists, and hashes.
• In memory, key – value data store.
• You are performing data sorting and ranking such as gaming leader boards.
• You have advanced datatypes such as lists and hashes.
• You need data persistence.
• You need multi availability zone.
• Use cases
• Database under stress which requires service to alleviate this.
• Elastic cache is a good choice. If your database is particularly read heavy and not prone to frequent changing.
• Disadvantages
• Caching will not help alleviate heavy write loads, so you may need to scale up your database.
• OLAP queries
• If your database is feeling stress because you are performing online, analytical processing, think about right shift.

Memory DB for Redis

• It’s a massively scalable in memory database which scales from (GB to > 100TB).
• Massive, scalability, greater, then hundred TB
• It’s highly available is multi availability zone and includes a transaction Log fall recovery and durability.
• It can be Used as a primary database so the entire data set for an application can be stored in memory (instead of a database plus a cache)
• We get ultra fast performance supports greater than hundred million request per second. Microsecond read and single digit millisecond write latency.
• Uses
• Suitable for workloads requiring an ultra-fast Redis compatible primary database.
• High-performance applications that need an in memory database to handle millions of requests per second.
• Applications that are data intensive, low latency applications that also require high scalability.
• Micro services that have highly scalable architecture.
• Example, an online gaming company needs a way for millions of concurrent users to generate interactive 3-D digital world and share digital assets.
• Memory DB and elastic cache
• Memory DB and elastic cache are both in memory data stores in that health application to access data faster than reading from disks However, there are certain differences which are as follows.
• Elastic cache for Redis is an in memory cache for database service. Sits in front of database like RDS. Memory DB for Redis can be used as your primary database reduce, complexity by removing the need for a database plus a cache.
• Elastic cache Fast but not ultrafast, millisecond, read latency. Memory DB is Ultrafast performance, microsecond, read and single digit. Millisecond write latency.
• Use case, elastic cash can be used for a website that needs to store session data for its customers. Memory dB can be used for an online gaming company with millions of users, sharing digital assets.