Amazon Quantum Ledger Database was released, and Flow Logs allow the addition of meta-data.
Because Blockchain supposedly solves all problems1 similar to Kubernetes2, over the past couple of years, it’s become one of those terms that are overused. That doesn’t mean there are no legitimate use cases for what it does, however, and because of that at re:Invent AWS introduced two different products related to this.
The first of these, Amazon Managed Blockchain was made available in April. I didn’t write about it at the time, because quite frankly there aren’t that many use cases for it and I wasn’t very interested in it3. The second one, Amazon Quantum Ledger Database or QLDB, was released last week.
QLDB is more interesting in a couple of ways. First, I feel like there are likely more use cases for it. Like “regular” blockchain, QLDB uses individual “blocks” as a way to enforce a trusted record of events. However, these records are stored centrally and not shared with the wider world. As you can see by the name it is treated as a database, but one that only allows inserts. No updates or deletes are possible, which means it is suitable for tracking types of data that require data integrity, and verification of that integrity, but without the need to share this data in a network that does the verification.
The other interesting thing about it is that I feel like it might be the first new service using PartiQL, the cross-database SQL standard AWS introduced back in May. As I pointed out at the time, it’s still just a standard that is used by a single vendor, but they seem very serious about rolling it out across their services.
Which is good. In the end, if AWS ensures that all of their various databases (and database-like products) use a common language, it makes it a lot easier to use these. Which, personally, interests me more than QLDB itself.
VPC Flow Logs Meta-Data
An interesting improvement to VPC Flow Logs was announced, where it now supports the addition of meta-data. This means that you can now add information about which VPC, subnet, instance-id, and a host of other data points generated a particular log entry.
For those needing a refresher, Flow Logs is a way to track all of the traffic that passes through a VPC. That includes both internal traffic and traffic that only ends or starts there. This was a good way to see the traffic flows within your systems, and aside from the obvious use cases like detecting attackers I’ve used it plenty of times even just to debug security groups or traffic routes.
All this debugging did mean that you had to know the IP address of your instance as that was the only way to find out if a log entry belonged to it. That was workable4 but did include an extra step. And if all your logs ended up in the same place that only made it harder to find what belonged to which one. The inclusion of this meta-data makes it easier to find what you’re looking for.
That said, as the meta-data gets prepended (please read the announcement post for details) it does mean that all of your log collection and collation tools will likely need to be updated before you can use it.
Read more like this:
- Week 21, 2018 - Amazon Aurora Backtrack; SAM init; GitHub Checks API
- Week 43, 2019 - CloudWatch Anomaly Detection; Some AWS Container Updates
- Week 39, 2019 - Step Functions Dynamic Parallelism; S3 Same-Region Replication
- Week 37, 2019 - Lambda Shared ENIs; EKS IAM Roles
- Week 34, 2019 - App Mesh Routing; Nested Step Functions; CodeBuild Runtimes
Or always get the latest by subscribing through RSS, Twitter, or email!