“The whole storage class is optimized… to give you dynamic pricing based on the access of that object so you don't have to think about how you pick your storage,” she said.
But only if you don't need to think about the bills...
At its virtual re:Invent conference, AWS presented faster block storage based on its custom Nitro hardware, strong consistency in its longstanding S3 (Simple Storage Service), and a solution for users forced to buy more storage capacity when all they needed was greater throughput. Although storage is less trendy than areas …
That is what will defend your application from being infected by malware.
Start using Rust, as it eliminates all the C/C++ memory unsafety bugs. According to the CVE database, that is 70% of exploitable bugs.
And yeah, hire engineers with a CS degree, who know how to write proper, strict parsers and semantic data checkers instead of hodgepodge code.
So curious to the WORM implementation. Are we walking optical storage? Storage on hard drives with the read only flag set? Supposed permissions on the Linux server preventing anything but read only? What if the file truly changes?
ANYTHING online can get attacked by ransomware with probably the exception of Optical Storage which has its own issues as well. Does not mean they cannot steal the files and hold THOSE for ransom (I mean who really needs to encrypt files if you have all of their sensitive files?)
Maybe it is too late to think properly, But I see this as possible misleading marketing.
The EBS options are maddening. There are multiple EBS description pages of varying obsolescence and completeness. Once you find one that looks current, you can spend a good 4 hours trying to figure out which ones to use. GP2 is the cursed storage with a burst balance and throughput that varies by size. GP3 is better but not always documented. Then there are ephemeral devices, which are allocated like EBS but not EBS. If that's not all crazy enough, EBS is assigned to instances using a device identifier that has no relationship to the actual device path. The actual device path varies by instance type and storage type so your init scripts can do little better than guessing where everything is.
So you want to start up your instance with lots of data? Amazon recommends EBS snapshots. Just map EBS device to a snapshot and... and... and... and you're still waiting for processes to launch. EBS snapshots perform at 4 to 16 MB/sec until converted into something more local, but not actually local. You don't need to scale up with less than a day's notice, do you? AMIs aren't a workaround because they're snapshots too. You have to subscribe to Fast Snapshot Restore to make it faster. Exactly how fast? Faster. Think you'll pull in data quickly from another service? You'll have to allocate the IOPS for that and pay for it for the life of the volume.
Oh, and can the S3 API please support streaming upload so temp files aren't needed to calculate the final size? You know, because the /tmp directory is an EBS volume.
Biting the hand that feeds IT © 1998–2022