Where database blog posts get flame-broiled to perfection
Alright, settle down, kids. I was just trying to find the button to increase the font size on this blasted web browser and stumbled across another one of these pamphlets for the latest and greatest database magic. "Amazon Aurora DSQL," they call it. Sounds important. They're very proud of their new way to control access using something called PrivateLink. It’s… it's adorable, really. Reminds me of the wide-eyed optimism we had back in '83 right before we learned what a CICS transaction dump looked like at 3 AM.
Let’s pour a cup of lukewarm coffee and walk through this "revolution," shall we?
First, they're awfully excited about these "PrivateLink endpoints." A dedicated, private connection to your data. Groundbreaking. Back in my day, we called this a "coaxial cable" plugged directly into the 3270 terminal controller. You wanted to access the mainframe? You were in the building. On a wired terminal. It was a "private link" secured by cinder block walls and a security guard named Gus. We didn't need a dozen acronyms and a cloud architect to figure out that the most secure connection is one that isn't, you know, connected to the entire planet.
Then there's the other side of the coin: the "public endpoint." So let me get this straight. You've taken the most critical asset of the company—the data—and you've given it a front door facing the entire internet. Then you sell a complex, multi-layered, and separately-billed security system to try and keep people from walking through that door. This isn't a feature; it's you leaving the bank vault open and then selling everyone on the quality of your new laser grid. We learned not to do this in the 90s. It was a bad idea then, and it's a bad idea now, no matter how many layers of YAML you slather on it.
This whole thing is a solution to a problem they created. The data isn't on a machine you can point to anymore. It's floating around in the "cloud," a marketing term for "someone else's computer." So now you need this baroque networking labyrinth to get to it. I miss the certainty of a tape library. You could feel the weight of the data. You knew if a backup was good because you could see the reel spinning. When the DR site called, you put the tapes in a station wagon and you drove. Now you just pray the "availability zone" hasn't been accidentally deleted by an intern running a script.
In this post, we demonstrate how to control access to your Aurora DSQL cluster... both from inside and outside AWS. Oh, goodie. A tutorial on how to point a fire hose at your feet from two different directions.
They talk about this like it's some new paradigm. Controlling access from different sources? We were doing this with DB2 and IMS on the System/370 before most of these "engineers" were born. We had batch jobs submitted via punch cards, online CICS transactions from terminals in the accounting department, and remote job entry from the branch office. It was all controlled with RACF and lines of JCL that were ugly as sin but did exactly what you told them to. This isn't innovation; it's just mainframe architecture rewritten in Python and billed by the second.
And the complexity of it all. The diagrams look like a schematic for a nuclear submarine. You've got your VPCs, your Route Tables, your IAM policies, your Security Groups, your Network ACLs... miss one checkbox in a web form you didn't even know existed and your entire customer database is being served up on a TOR node. We had one deck of punch cards to run the payroll report. If it was wrong, you got a stack of green bar paper that said ABEND. Simple. Effective.
Mark my words, this whole house of cards is going to come crashing down. Some junior dev is going to follow a blog post just like this one, misconfigure a VPC Peering Gateway Connection Endpoint, and the next thing you know, their "serverless" cat picture app will have root on the payroll database. And I'll be the one they call to figure out how to restore it from a logical dump I told them to take in the first place. Kids.