Preface
Why Is This Book Needed?
Once upon a time, during those thrilling yesteryears of information technology history (circa the late 1960s and early 70s, when “Information Technology” was called “Electronic Data Processing” abbreviated “EDP” -- not “IT”), an IBM computer scientist, Edgar F. “Ted” Codd , conceived and published his theories on the relational model for database management.1 Upon his pioneering shoulders have stood many IT professionals, authors and entrepreneurs, who consequently evolved civilization’s contemporary relational database management systems (RDBMS) along with a thriving, competitive, multi-billion dollar worldwide marketplace. Among them were Raymond F. Boyce and Donald D. Chamberlin (also IBM computer scientists) who co-developed SQL (the Structured Query Language) which itself has evolved to become the most familiar and frequently used language for accessing and manipulating RDBMS data.2,3  
Many years of research, product innovations, versions and releases have blessed humanity with a variety of robust, modern-day, commercially available, SQL-based relational database products (e.g., Oracle DB, Microsoft SQL Server, IBM Db2, etc.). Relational databases are now the foundation of many mission critical, enterprise scale applications such as ERP (Enterprise Resource Planning), CRM (Customer Relationship Management), and SCM (Supply Chain Management) systems -- driving online transaction processing (OLTP), analytical processing (OLAP) and other operational databases for countless customers world-wide.
And you -- the curious but skeptical reader -- are likely a veteran IT data professional possibly with substantial relational database background and experience. Your successful career, having yielded uninterrupted paychecks, has focused on the mainstream of IT with its apparent fixation on relational databases -- and likely you’ve productively contributed to, and lucratively benefitted from, a variety of IT projects, such as:
You, an unrelenting student of IT, owe much of your professional success to your unquenchable thirst for knowledge. You’ve acquired and maintained your knowledge of many of the above mainstream subject areas. Powered by the confidence of that knowledge, you have become the “go to” gal or guy for pontificating opinions on many data management challenges facing your enterprise. As a result, perhaps you are (or will someday ascend as) the CDO -- the Chief Data Officer -- for your enterprise, flaunting your RDBMS subject matter expertise. The data that defines the business world, from your perspective (IT life as you know it), rests by and large on relational database technology, your professional and technical comfort zone.
But your conscience, that inner silent voice, cautions … “You can never rest on your knowledge laurels and stop studying IT” … because …
“Once you stop learning, you start dying” (Albert Einstein)
and …
“If you rest, you rust” (Helen Hayes).
Inspired by a growing number of interactions with other IT professionals …
… you begin to suspect that times are changing for the relational status quo … that there’s now much beyond IT data life than relational stuff. They toss around numerous, non-relational concepts, buzzwords, and acronyms:
Graph databases, document databases, NoSQL query languages, GQLs, in-memory databases, cache server clusters, cloud database platform services, MPP, immutable ledger databases, blockchain technology, etc.
You are also overhearing scuttlebutt about new use cases and applications that appeal to non-relational solutions, and that new non-relational cloud data services are now ready for prime time … ready for serious consideration:
No worries … change is a good thing … you’re optimistic! You’ve grown (and not groaned) through many IT paradigm shifts throughout your career (i.e., many OS, ERP, and RDBMS mergers, acquisitions, and migrations). Now a new paradigm … a new challenge …
from Relational to Non-Relational!
You envision that these new concepts and use cases can be exploited as opportunities to amass additional IT knowledge, wield intellectual power, speak with professional authority beyond your RDBMS comfort zone … and you can emerge as a renowned non-relational hero! So as always, once again, you will be open-minded to these non-relational approaches now available in the cloud.
Fortunately, your enterprise is likely already familiar with moving apps to the Amazon cloud (AWS), having either begun the planning process or actually transitioned pieces of your apps to the cloud (i.e., the low hanging fruit -- the web servers and app servers that “reach back” to databases in your private data centers). But now your insatiable CxOs want more cost savings and additional data center footprint reduction. They now want your database servers moved to the cloud! They also want to understand these new non-relational database services as well! Why? Because of new “business imperatives” for competitive advantage: Faster response times for a new global shopping cart app, developing prototype recommender systems, faster time-to-market for apps development, cyber-security and data immutability … blah, blah, blah. And they want you to deliver presentations, plans and proposals for all of the above … pronto!
So you, like many IT professionals world-wide, are currently confronted with the challenge of quickly absorbing basic concepts surrounding the ever growing variety of AWS database services. You will need to do some cramming! As before, because of traditionally tight training budgets, you once again proactively google “AWS documentation” this time for unravelling AWS database services. You are shocked by many user guides, developer guides, and programming reference documents -- over 20 documents -- covering an impressive array of services. You hunger for a high-level summary -- with diagrams and pictures worth thousands of words -- that you can rapidly reuse for promptly producing your presentation.  Alas, you quickly conclude that none such synopsis exists.
Introductory videos stun you with the robust collection of AWS database services offering many options for migrating existing relational databases, creating non-relational databases, and many new data concepts beyond your relational security blanket. You also astutely absorb from the user guides that AWS database services are described by a plush “Tower-of-Babel” vocabulary of many new fundamental concepts -- far deeper than water cooler and happy-hour discussions with IT colleagues:
Cluster Nodes, DB Instances, Event Subscriptions, Option Groups, Parameter Groups, Replication Groups, Node Groups, Ledger Databases, Merkle Trees, etc.
Along with basic cloud infrastructure concepts:
Regions, Availability Zones, Accounts, Virtual Private Clouds, Subnets, Instances, Security Groups, Subnet Groups, Resources, etc.
Their esoteric terminology and concepts are inextricably intertwined by many relationships and described by thousands of pages of detailed, technical prose, supported by many intuitive diagrams. Yet, nowhere, within this vast compendium of documentation can you, a veteran shepherd of data, find the one thing that would allow you to develop an instinct for how all of these pieces fit together. You suspiciously wonder …
Is there no data model ?
What’s a data model? As a data professional, you understand that a data model is primarily used for designing databases. But a conceptual data model can serve as a mind map for visually understanding basic concepts (entities) and relationships between entities for any complex subject area -- not only a database. Your data modeling intuition kicks in -- you pull out your trusty yellow lined legal pad and you begin to doodle these newly discovered AWS database concepts as entities. Separate boxes indicate Clusters, DB Instances, Parameter Groups, Parameters, Option Groups, Replication Groups, Node Groups, and many more concepts -- drawing lines in between to represent the complex relationships connecting these entities. But then, you ponder to yourself …
You quickly skim through all of the user guides. No data model found! You peruse other related docs … again none found. How about general web searches … image searches … again none found! Sadly, it appears that no persuasive, compelling data model has yet been proposed or published for AWS database services. You will need to slog through thousands of pages. You’d rather tolerate a root canal … a colonoscopy … or a frontal lobotomy!
Unmistakably, your IT instincts suggest to you that the cycle time for achieving a confident overall understanding of AWS database services can be substantially squeezed with the help of a conceptual data model summarizing their many concepts and interrelationships. A concise data model can easily clarify your confusion, dissipate the daze, and diminish the duration for coming up to speed with AWS database services.
So here, to the best of this author’s knowledge, is likely the first attempt at publishing a conceptual data model for AWS database services. Let this be a testimony to the hope and trust that data modeling can possibly serve as a fresh approach for unravelling the knots of any obscure, nebulous, and highly technical subject area. The venture of attempting to quickly comprehend and contrast AWS database services is indeed one such thorny challenge. Herein you will enjoy numerous, and hopefully intuitive, entity-relationship diagrams; the result of an earnest effort to demystify the complexities of AWS database services. 
This endeavor is a consequence of reverse engineering and visually interpreting the narrative found within the library of AWS Database and EC2 documentation ,4 at the time of this publication, specifically:
Your feedback, suggestions, and improvement concepts, via social media or otherwise, are eagerly welcomed; and in conjunction with any major updates to the aforementioned references combined with God’s willingness, will serve as the basis for future editions.
Who Should Read This Book?
Many IT professionals from various walks of IT life will benefit from the content herein:
What You Will Find
This document will take you deep down the “rabbit hole” into the wonderland of Amazon Database Services -- for a tour of their fundamental concepts and related details, visually supplemented by many intuitive data modeling diagrams. Here’s a brief summary of what you will find:
About The Author
Henry M. Nirsberger, also the author of A Conceptual Data Model for Amazon EC2 , earned an MS in Systems & Information Science at Syracuse University and BA in Mathematics, Le Moyne College. His professional IT career spans five decades starting as a software engineer with Honeywell Information System in 1974, continuing with GE in 1979. While at GE, he assumed a variety of technical, project management, and management positions, culminating as a Senior Architect for GE’s Corporate Enterprise Architecture Team, having gratefully contributed to hundreds of IT systems and applications development projects. Currently the CEO of HMN Consulting LLC, specializing in enterprise architecture and data management consulting services, his past professional certifications include CDMP (DAMA), CBIP (TDWI), CFPIM (APICS 1984–2003) and TOGAF 9. As a trained facilitator (MGR Consulting), he facilitated over 600 IT design and planning sessions for data modeling, process modeling, database design, project planning, process improvement, requirements consensus and team building. Presently, he remains a student of data modeling, cloud computing, enterprise architecture, cyber-security, and all aspects of data management.
Acknowledgments
The author gratefully appreciates and acknowledges the efforts of the editors and reviewers of this endeavor.  Editing services were adeptly delivered by Bernard E. Durfee (Lambda School), William Rielly (Principal Analytics Engineer, CDPHP), Jennifer K. Senich (VP Operations, Ithos), and Addie Nirsberger (the author’s perfect 10 wife, best friend, and soul mate). The author also salutes Bernard E. Durfee for inspiration and ideas used for portions of narrative in the introduction chapter. The book cover was designed by Bob Sacca, one of the author’s all-time favorite GE managers. The author is also grateful to Joy Ruff (Product Marketing Manager, IDERA) for exemplary customer support and providing an evaluation license of IDERA ER/Studio Data Architect from which all entity-relationship diagrams herein were created. The author also recognizes the outstanding support and infinite patience demonstrated by the Amazon AWS Support Center, whose technical support staff rapidly responded and proficiently resolved 79 cases for questions on all Amazon database services raised by the author over a period of several months.
Dedication
This effort is dedicated to Mom and Dad … Anna and Michael … intrepid immigrants to America … in search of freedom and opportunity. The memory of your love, laughter, values, determination, and encouragement for continuous learning inspire me each day.
Henry M. Nirsberger
Clifton Park, New York, USA
Henry.Nirsberger@gmail.com