101–110 of 355 posts
Storage Gateway: Virtual appliance to couple on-premises applications to storage in the cloud.
(So it's no iSCSI (block) to S3 (object) but Block(iSCSI to EBS), File (SMB/NFS/S3 to S3), or Tape (iSCSI VTL))
Addition:
VMware Cloud on AWS: Bare-metal, automatically deployed VMware clusters on AWS hardware.
Consider that your typical enterprise software project will use quite a lot of these, and that you pay for them all separately, and sometimes pay twice for them (e.g. S3 you pay for storage and for outbound bandwidth). It's quite a tour de force how Amazon have taken "separation of concerns", applied it to web services and used it to create complex and difficult to understand or predict pricing to print money. Bravo.
Have you ever used AWS? There's a whole suite of tools they provide around pricing and budgeting. > It's quite a tour de force how Amazon have taken "separation of concerns", applied it to web services and used it to create complex and difficult to understand or predict pricing to print money. Is applying separation of concerns to web services really that bad? Look, if you're a small company with a simple product, yo…
> VPC Create your own VPCs within AWS Not particularly helpful if you have no idea what a VPC is! Of course it takes 2 seconds to search this for yourself, but still.
Isn't VPC a wel known term? I guess the author just included that definition to make the list complete.
Earlier quoted context omitted.
I don't understand why I even need to do manual things such as "tagging" (besides learning what that even means in AWS) to find out something as simple as why I'm being charged as much as I'm being charged. I'm sorry. It's inexcusable.
And large organizations would complain about why they couldn’t group their resources like they want to. Having individual bucket costs would be of very little use for cost allocation and to tie back to something like a department. For instance, we tag every resource created with the same CloudFormation template with the same tag. We can get billing based on an “application” and all of its related resources. Just like…
Where's EBS?
Some corrections: AWS Outposts: Run Amazon services in your own datacenter (not on your own hardware) Storage Gateway: Virtual appliance to couple on-premises applications to storage in the cloud. (So it's no iSCSI (block) to S3 (object) but Block(iSCSI to EBS), File (SMB/NFS/S3 to S3), or Tape (iSCSI VTL)) Addition: VMware Cloud on AWS: Bare-metal, automatically deployed VMware clusters on AWS hardware.
Consider that your typical enterprise software project will use quite a lot of these, and that you pay for them all separately, and sometimes pay twice for them (e.g. S3 you pay for storage and for outbound bandwidth). It's quite a tour de force how Amazon have taken "separation of concerns", applied it to web services and used it to create complex and difficult to understand or predict pricing to print money. Bravo.
Overpriced, unnecessary or both.
Earlier quoted context omitted.
Have you ever used AWS? There's a whole suite of tools they provide around pricing and budgeting. > It's quite a tour de force how Amazon have taken "separation of concerns", applied it to web services and used it to create complex and difficult to understand or predict pricing to print money. Is applying separation of concerns to web services really that bad? Look, if you're a small company with a simple product, yo…
> Have you ever used AWS? There's a whole suite of tools they provide around pricing and budgeting. They don't work. To elaborate, they fail to provide the user with information with enough clarity to allow him to form accurate mental models of what is being used,what it costs, and what is the implication in cost of applying some change. Heck, at any given moment it's unexplainably hard to tell exactly which AWS serv…