A Comprehensive Guide to Building a Scalable Web App on AWS
airpair.com
airpair.com
Normally when I learn something new, I learn by tinkering and breaking stuff. I don't feel comfortable doing that with AWS. I'm hoping people will tell me I'm way off base because this fear has stopped me from getting the ball rolling.
More about bots scanning github for api keys, that's pretty scary in itself because I know pushing keys by accident happens a lot.
1) You're just playing: You want a limit. 2) You're serious about it: You want a warning.
Easy enough to understand I hope.
You just have to set it up, and if you cannot be bothered, AWS isn't the service for you. If you don't want to do your own cooking, fine, but don't whine about the grocery store not providing you with your own personal chef.
oafitupa is just whining for the sake of whining.
This is hacker news, ie for people who like tech, like to ticker with it and play with it. What is so bloody wrong with wanting a safety button so that you don't ruin yourself that you have to throw out insults?
They give you enough rope to hang yourself. I'm ok with that, because it works brilliantly when you have the time to put in to it. (They also almost always help out or completely forgive someone that accidentally ran up a massive bill in a short period of time.)
Without AWS, my company wouldn't exist - I could never have initially afforded dedicated hosting or collocation. AWS changed the game. You can argue they're not the cheapest or even the best anymore, but it works this way because of Amazon.
Edit: what's with the down-votes?
So maybe AWS isn't the right solution for you. You say in another comment that warnings about billing overages aren't enough. AWS can't hold your hand and provide Netflix-capable services at the same time.
Amazon chose the latter. I would recommend you not choose AWS until you have the time to dedicate to it.
I don't want to "play" with VPS servers, I want to work knowing that I won't go bankrupt just because I'm using at the same time a service that won't let me set up a limit, and a pull payment system (ie. credit cards, as opposed to push systems like Bitcoin).
It's like saying "this website is stupid, it's storing passwords in plaintext", and you answering "hurr, it's the user's responsibility to create and manage cryptographically secure passwords".
And as an analogy, Aws is more like C; if you are willing to put the time in to learn, you can do some amazing things that are impossible with other providers. But you must take responsibility for them.
I'd love to hear use cases where legitimate businesses, who make money off of the products or services they offer, can literally afford to have their business just stop working. It sounds totally contrived.
In fact, we use an SNS->Slack gateway running on a free Heroku dyno to get out alerts in a Slack channel (which is pushed to phones/etc), along with other CloudWatch alarms related to performance.
Honestly, this issue of "I don't have any visibility into what I'm spending" is a waste of energy. You do, and you can have AWS bug you as intensely as you want with updates as frequent and as urgent as you need
It's always best to leave termination of your client's systems up to the client than to pull the plug out from under them... at least I'd like to think that's how they would have reasoned it internally.
Amazon is very easy to work with, if you simply tell them that you are an idiot and fucked up. You're not the only one.
Amazon probably should do a credit check before offering thousands of pounds in credit...
(I am not a lawyer and this should not be taken as legal advice)
(They also almost always help out or completely forgive someone that accidentally ran up a massive bill in a short period of time.)
But, and I don't say this lightly, your behavior in this thread makes me think you just want to complain.
Then there are the ancillary benefits - I can lose a server and another is in its place, attached properly to the stack within 60 seconds. I can take advantage of compute power when I need. I don't have to run nginx or haproxy for load balancing (and I don't have to manage the load balancer servers) and spinning up an identical stack in Europe or Asia is a single command line statement away.
Also I'm not a server admin by trade.
So I realize there are scenarios where bare metal could be cheaper, but the opportunity and admin costs need to be factored as well.
There are a number of colo providers that also provide managed hosting and cloud services (even if you for some reason couldn't deal with the latency of simply tieing EC2 instances into a colocated or managed hosting stack via a tunnel).
In fact, combine, and you can cut the hosting costs even more than with colo services alone, since you don't need to plan for a low duty cycle for the hardware - you can run things on 90%+ load (or wherever your sweet spot turns out to be) under normal circumstances and fire up cloud instances for the spikes.
That method handles the loss of servers etc. as well just fine, again further cutting the cost of a colo/managed hosting setup because you can plan for less redundancy.
Personally I've yet to work on any setup where the admin costs of an AWS setup has been nearly enough lower than colo or managed hosting to eat much into the premium you're paying. You have 90% of the sys-admin hassles anyway, and you're left with far less possibility of tuning your setup to what works best with your setup.
Most of the setups I've worked on come out somewhere between 1/3 to 1/2 of the cost of running the same setup purely on AWS. Sometimes the gap is smaller if you have really spiky traffic or have lots of background processing or one off jobs where you can e.g. use spot instances extensively.
I do understand people wanting to pay to not have to think about these things, though. But you're almost certainly paying a steep premium for it, even with your traffic spikes.
And you don't need to straddle data centres as most data centre operators these days have their own cloud offerings - often cheaper than EC2.
I don't know his margins, so maybe it isn't worth it for him specifically, but I know plenty of businesses with small enough margins that the opportunity to halve a half-a-percent-of-revenue cost like that could easily add 10% to profits.
You now have one environment trying to talk to a database in another location, for example. So, some requests are artificially slower than others. You could mitigate that with caching, and probably already do, but now your cache is fragmented across two, or more, environments. On and on and on and on.
Configuration, security, duplication of resources that can't be easily shared. These aren't unsolvable problems, but they're relatively more complex than sticking everything in a single environment.
And yeah, the money aspect could easily be worked in either of our favor. It really depends on the specific situation.
If you understand AWS pricing, and don't publish your AWS keys, you should be good to go.
* Committing root credentials to a public git account (equivalent to your root account on every machine + ability to purchase new servers…) * Spinning up instances during free period, then forgetting and getting billed the $10/month on them a year later * Not reading the costs, and trying to replicate what you might normally purchase in AWS and being surprised at the cost, rather than buying 101% of capacity required.
I'm using it to host a mid sized website with an intranet type app with servers spanned across multiple data centres, built in redundancy etc for around $100/month after reserved instance one off payments. It's crazy cheap and in my view, incredibly powerful even for smaller businesses.
Much respect for the amount of work that went into this. I'll try to get through it all here at some point :)
Few examples such as: 1. What are the security measures somebody needs to put in place to host a HIPAA compliant Web app etc.
2. What are the popular stacks that can be set up on AWS without much hassles and with less expertise.
3. What are day to day activities required to maintain few web apps on AWS. etc
Flexibility of networking, Regional coverage, Tooling , Performance,
On the cost side with reserved instances it's less expensive.
Having said that, nothing beats getting real hardware in terms of performance/$. I used to work for a company that exclusively worked on SoftLayer's hardware servers. These were $500+/month each, but they were fast. The point is that if you can devote a dual octocore machine to what you are doing, and are willing to pass up on the SAN, flexible networking, etc. then you get a very fast box. If what you are doing requires lots of very fast hardware, then yea AWS or anything like it is not really for you. But if you are like most people, your AWS bill is not going to break the bank and you can just spend one less billable hour figuring out why the server is slow, and just double its size.
I use AWS, and will continue to use AWS, because it means less screwing around with stupid things and more time making important things work.
Since you're writing to multiple EBS volumes for the RAID 1 portion of the RAID 10, you're going to require more EC2 to EBS bandwidth.
EBS volumes are replicated across multiple servers, so you don't necessarily need the reliability, especially if you're replicating the data elsewhere.
YMMV, of course, and everyone has different priorities and different levels of what constitutes acceptable risk, but RAID 0 with EBS isn't quite the data death wish it is with physical hardware.
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/raid-conf...
No, it's not. It is if you want data-at-rest storage, but I don't care about that when I have multi-master MySQL and Postgres running on instance stores. Or when I have replicative NoSQL databases (Riak is more than happy running forever in instance stores and duping across AZs).
I'm not suggesting that's ideal for all companies, but this idea that somehow it's impossible to run a load balancer or store files without using AWS/Azure/Google 'clouds' is a bit ridiculous.
Running an FTP server != an S3 equivalent.
For the majority of those people, a simple SFTP/rsync/NFS/whatever endpoint (potentially with replication to provide redundancy) would more than fit the bill, and would actually be simpler to use than the S3 API.
For larger setups you can do it at 1/3 or less of the cost if you're prepared to go the colo route (rather than managed servers) and leasing your own hardware.
If your average bandwidth usage per object is high you can trivially cut costs far beyond that, as the EC2/S3 bandwidth costs are atrocious.
The exception would be if you can't avoid huge amount of object accesses from within EC2 even if you move the storage out of S3.
The same resources that Sysadmins used to learn how to do it?
Or hire a sysadmin part-time.
What they are really competing on is breadth and depth of service. The article goes into a lot of those services, but, as one example, if you launch an instance in EC2 you can allow it to access secured buckets in S3 without any need to store keys/passwords on the instance itself thanks to IAM roles.
Another example is services like AWS Lambda, which is a hosted way to run a function without any need to manage servers.
The list goes on and on...direct VPN connectivity, Hosted Active Directory, CloudHSM. While I'm biased, my perception is that AWS is pretty far ahead of the pack.
Look at Reddit, they have very few employees yet they can't make a profit because their hosting costs are massive.
Contrast them with StackExchange, which uses a small number of powerful, well-optimized servers and is very profitable.
Kudos to you for touching on containerization, I would just like to add that the many emerging platforms and tools (https://pbs.twimg.com/media/B33GFtNCUAE-vEX.png:large) are rapidly starting to provide an alternative to AWS that was not there before in their ability to realize more competitively priced hosting alternatives without sacrificing on administrative overhead.
Not valuing your time is easily among the biggest mistake you could make.
The real trick with AWS, IMO, is figuring out what you want to do yourself vs what you want to have hosted. For example, they offer a hosted cache such as memcached or Redis. For my app, I run Redis myself as it required roughly 15 minutes of work total to set up and maintain in 2014. OTOH, that's not nearly the case with Postgres. I spent a day and a half tuning the version I host, switching to RDS, then switching back because RDS was too slow (even though by the specs, it was using a more powerful VM than the EC2 box I was running my instance on).
Basically, once you grok AWS, things become more productive AND you don't need to spend time on doing things like setting up VLAN's, transferring data between boxes, etc. You can do cool things like detach a virtual disk from one VM and attach it to another, rather than pushing 100 GB's of data over a network. This, AFAIK, is not something that Linode or Digital Ocean can do.
Having said that, DO is great for lots of things. It's a good place to experiment and to run lots of really small things. For me, that's side projects or things that I am trying out before thinking about moving them to the "big iron".
> OTOH, that's not nearly the case with Postgres. I spent a day and a half tuning the version I host, switching to RDS, then switching back because RDS was too slow
These two statements are contradictory.
You would have been better off just renting a dedicated host for your DB and doing the tuning yourself (either in person or getting someone to do it) - because the AWS offering is slower than your own instance, and database is a service thats often ripe for easy optimisation by using a dedicated host/cluster of hosts vs virtualised host(s).
My point about physical was just another common optimisation for performance critical DB servers, you could probably get close to bare metal speed with the flexibility of virtualised by using a "single VM on hardware" model that some providers offer now.
The point is you aren't locked to a single vendor. Heck, even mix and match - replicate your services across providers, across data centres.
A 60GB r3.2xlarge spot instance on AWS will cost you about $50/month while on DO you'll be paying $640/month for a 64GB machine.
Granted, the DO machine will be way more performant, and you have to have a workload that suits spot instances.
Every time I look at things like DO to see if I'm missing out I price up my current AWS setup and they're always astronomical (for my use case).
Then there's all the other control around AWS; it's so much more advanced than all the other services. Nobody else really comes close to the flexibility they give you.
For a lot of (probably even most) web apps that probably doesn't matter. Have a look at your use case and decide if AWS is worth it.
In every other regard - disk space, CPU cores, data transfer, availability - the AWS spot instance option is MUCH worse than a regular VPS like from DO, or even a dedicated physical host.
Ignoring the CPU core difference, a regular (i.e. so you can use it all the time) instance with extra EBS storage and data transfer to match the DO instance you mentioned, would be $1500/month.
Places like Rimuhosting will rent you a pre-used dedicated server with 128GB RAM, 2TB HDD + 200GB SSD Dual Xeon (12 cores, 24 HT) physical server (which you can then run a single Xen VM on, for better portability) for $400 a month. Yes it's more than your $50 a month, but its completely yours, for as long as you want it.
To truly take advantage of a spot instance and NOT have it impact your business, your workload needs to be very tolerant of interruptions and variable processing time per day. For the vast majority of people using EC2 (web/app servers running 24x7) it's not a realistic option.
Aside from that though, spot instances aren't that volatile. I have some that have been running for months. Obviously they're not always at the low low price they can be, but if you average it out, they're not much higher than that.
In total honesty, I don't use those machines I mentioned. I use ones with 32gb ram and much better CPU performance. I need that ram for what I'm doing and any other provider I've found comes in a lot more expensive to satisfy that requirement. The CPU I get is good enough for what I'm doing.
But again, I don't know anyone other than Amazon that has an infrastructure that flexible at that price.
If there's anything incorrect with what I've said, please point it out. I'd love to know about other providers that would give me more bang for my buck.
Is it the assertion that spot instances are a viable option for some use-cases? Is it the fact that I compared something to DO?
http://journal.dedasys.com/2015/01/22/when-to-use-aws-and-wh...
tl;dr: I would not use AWS unless you know that you need what it offers.
EC2 seems to handle all that nicely by letting you just upgrade instance types as you need them, and providing burst performance for spikes in traffic. It seems like a pretty fire-and-forget solution and I've not paid them any money yet (10 days, 30,000 hits)... So far I'm happy but really I've no idea what I'm doing.
This conversation didn't ever seem to bottom out to conclusion? In particular I was wondering how servers connected _outwards_ in the VPN scenario.
I'm using a Bastion setup, so don't get me wrong, just want to understand how strong the pros are for the VPN route.
On your last note. I just run one Bastion as a general rule. They're quick enough to spin up another instance (in a different AZ if necessary). Generally our services won't die if the Bastion or NAT is down.
Pros: - Logical isolation. You can put instances (and RDS, Redshift) etc. inside logical subnets that are not addressable from the outside world. - VPNs. If you really want extra security, you can wire up VPN so one of your VPC subnets shows up on your corporate subnet.
Cons: - A complete pain to manage with SSH-based tools. Most deployment tools (Ansible, for example) and even lower-level tools like fleetctl don't play well (if at all) with jump boxes. Example - Ansible Tower requires instances that are publicly addressable OR placing a Tower instance inside a VPC (which means we can't use it to manage multiple VPCs) - We have had to write our own workarounds for the above con. - Complexity. There are more concepts to learn about. - Lack of portability. I don't know if all cloud providers (Azure, DO etc.) even support VPCs the same way AWS does. This makes our infrastructure less portable than I'd like
I was asking less about VPCs in general, more the use of the VPN->VPC or Bastion approach to bridge into that network.
We disable password login on the ops box and set up 2FA on SSH connections. We haven't taken the step of whitelisting IPs but it's probably something we should do.
I just finished moving our last EC2-Classic service into VPC. It's been less of a headache than I anticipated.
The logic here being you'll only need certain things on the VPN, and you can put them or give access to them through the small subnets. You can simply use NAT to translate a /28, /29, or whatever to an available block in your corp network. This won't work for everyone, but I think for a lot of cases you don't need full access to the VPC via VPN and you'll know pretty early on if this will work for you or not.
I knew I'd see a bunch of people stating that AWS is expensive and you should use a dedicated server or a VPS. But there are many applications built by people like me who are lone developers or small teams of developers who either don't have the admin skills or simply don't want to admin their own servers and the fact that AWS handles quite a lot of this for you is sometimes worth the the added cost.
Obvious disclaimer: I work on CF for my dayjob.