For me-south-1 (Bahrain), all 3 data centres providing the redundancy were blown up by Iran.[1] The redundancy was localised to small geographic area and a single government--something customers of AWS were hopefully aware of when they entrusted AWS with their data.
It's always buyer beware for any claims of availability. Engineers completing a FMECA[2] will (or should) always state upfront what type of failure modes they've deliberately excluded (such as meteor strike) or else every FMECA would be full of failure modes that have never been measured, and are not worth anyone's time worrying about. These exclusions vary by application--a time capsule, seed vault, etc are intended to outlast wars and collapses of empires. Typically a bunch of data centres aren't designed to withstand such failures.
I do think however it'd be reasonable to include the prospect of war for calculating data centre / cloud service availability. Especially in a place such as Bahrain where the country is obviously concerned enough about the prospect of war to have built very permanent and expensive air/missile defence sites. New Zealand on the other hand--maybe not so important to consider.
Regions are really the scale of disaster isolation only in extreme cases - such as global catastrophe (meteor strike taking out a city) or in this case, when actively targeted in war. I don't really see the same thing happening to a US or European region.
As far as I know, the attacks happened at different times. If Amazon knew that they had lost some data redundancy, shouldn’t they have been quickly mirroring that out of the region?
"You choose the AWS Region(s) in which your content is stored. You can replicate and back up your content in more than one AWS Region. We will not move or replicate your content outside of your chosen AWS Region(s) without your agreement."
This. We have (well, had) customers running in me-south-1 and once the first AZ went down we wanted to proactively move their data to other regions even just as cold backups. But our legal department slapped that down pretty quickly.
Most likely, their own data residency terms prohibit this. It would be interesting to know if, when 2 out of 3 AZs got destroyed, customers got a heads up to move their data to a different region?
We received repeated, constant heads up to move our data by the first AZ much less second. The problem is that nobody is storing data in Bahrain unless there are data residency requirements for it.
nobody wakes up one morning and chooses to launch instances, CDN or S3 and would choose Bahrain as that without a requirement to, we were contractually and legally forbidden (in the middle as a vendor) to copy even encrypted data where we don't have the key out for redundancy, so the best we could do was tell our subcustomers to download all of their buckets to their office or some employee laptops at their office
Although the more paranoid AWS customers who turned on (and pay for) S3 cross region replication or similar cross region DR for other services would be fine.
Because your competitor can now produce 10x more work with the same resources that your company can only produce 1x, therefore in short order your company isn't competitive and will cease to exist.
No glare, but with a backlight and excellent battery life make this a great option for Engineering. The only thing that's missing here is a rear camera. Fingers crossed this is considered in the future!
There is nothing malicious about Alter Table or Drop Table commands. These all have valid use-cases and is not something an LLM needs to guard against.
If a bad-actor can issue these commands against your DB, you are already toast!
I think for many (though not necessarily most) busineses, especially micro-ISVs running a SaaS, the business cost of doing what they "should" be doing far exceeds the actual cost of letting bad-things-happen and paying for the cleanup afterwards.
As the designated "code-and-Red Bull-guy" at the micro-ISV I work at, I'll admit that I've unintentionally nuked the production DB at 2am - but fortunately our cloud database provider could do a point-in-time restore and everything was fully operational again by 2:30am. That's because the cost of setting up infrastructure and procedures to eliminate the need to ever manually run DML/DDL against our prod databases would be... probably a multiple of my salary - and be required indefinitely into the future (as that infrastructure would have to be maintained as the database's design changes over time too) - whereas the cost of having PITR on our prod databases in Azure is... a rounding error.
So yes, our prod is going to go down in future - we can't afford not to, honestly (it's a USA-only B2B SaaS, we get literally zero usage before 6am EST and after 7pm PST).
The college-hire is not the problem; it is the person who gave the kid prod access, or perhaps at a higher level, the person who architected the DB permissions structure. If one person alone can cause a production SEV, many things had to have gone wrong by many other people beforehand.
I remember having a test suite that would connect to a local db running in a docker container and would nuke the tables and then set up the records in a known state before running through. Worked great until someone changed the connection string to point at an actual database.
One possible trick you might consider is to (manually!) add objects to the DB's schema that explicitly indicate its environment, e.g. `CREATE TABLE dbo.ThisIsProductionYouSillyPerson ( DummyCol int NOT NULL );` for prod and `CREATE TABLE dbo.ThisIsTestFeelFreeToMessAround ( DummyCol int NOT NULL );` - these tables would be excluded from the automated DB deployment code - and write test scripts that all start by checking that the `dbo.ThisIsTestFeelFreeToMessAround` table exists and that the `dbo.ThisIsProductionYouSillyPerson` table does not exist in the DB before continuing.
DB automation is great for preventing mistakes during common routine operations, but because DB automation can also go haywire and delete drop all-by-itself unless you set-up out-of-band (if that's the right term?) safeguards. Having airgapped dev-test-staging-and-prod won't help you if if you forgot the `WHERE` in an `UPDATE` in a little-used script that the prod automation uses, that testing never discovered (which happens all the time, it's scary).
I do appreciate how MySQL does come with an `UPDATE-without-key` guard, but I'm surprised none of the other RDBMS have safety-guards like that - just a simple `RequireManualConfirmationForMultiRowDml` flag on a table would help.
I've only ever queried (very large) databases but my eyes always go a bit wide when i see statements that touch tables. They scare me. They scare me when i run them on an sqlite table i made 5 minutes ago for an experiment.
I see the problem as much, much more insidious and not the expected threat vector. The past few months many of us have seen these models become increasingly worse at keeping track of details and hallucinating.
They mix in information within their context window, and the cope that OpenAI has given us for their worse ability to generate good quality output is .... more context! Great.
So what happens when that context window (which you have no real idea how they're actually implementing it) has the concept of "DROP" in it? Or what happens when It's a long day, you looked over it and it's all correct, but in some buried inner query something changed? Probably it just costs some time to debug, bu..
Obviously there should be a few safeguards before that query gets executed but i never want to see an increasingly cheapening and more wide-spread black box like GPT be able to "speak" a word which in principle can cost 6-7 figure damages or worse.
We don't let actively hallucinating people brandish firearms for a reason
Also look at all the post processing and AI that goes into smartphone cameras right now. The human element doesn't even choose which photo this is done algorithmically and the photo is stitched together in lots of different ways. The human just prompted: 'Now!'
If I can see the code and clone the repo then regardless of whether Github allows me to automatically fork it, I can fork it myself just be adding another remote.
This plus Siri would be amazing.. I live in HK with very limited space and a lot of apartments that don't allow pets. Plus it's Asia so people will go wild for this..
Perhaps this is planned with Aibo, which would be very cool, but I didn't see it mentioned on the webpage or press release, and it will be very difficult to make a 190,000Y sale on an iPhone alternative with fewer features that doesn't fit into your pocket. If it sells, there needs to be more than a reason for a Siri-like feature, but I still don't see it.
reply