AWS mistakes to avoid
cloudonaut.io
AWS mistakes to avoid
1–10 of 276 posts
Re: AWS mistakes to avoid
#2Also, dont use Dynamo unless you have a really good reason. "It scales better than MySQL" is not a good reason.
Have fun migrating data and re-indexing constantly!
Re: AWS mistakes to avoid
#3I second the recommendation to use CloudFormation + packer + ELBs + auto scaling groups for web applications whenever possible, it just makes everything so easy and automatic. Of course, there's a learning curve and you pay a premium for all that automation, but in my experience it has been usually worth it so far.
Re: AWS mistakes to avoid
#4Also, dont use Dynamo unless you have a really good reason. "It scales better than MySQL" is not a good reason. Have fun migrating data and re-indexing constantly!
Beginner here, how do you keep the database available to multiple instances without Dynamo?
Re: AWS mistakes to avoid
#5[deleted]
Re: AWS mistakes to avoid
#6[deleted]
+1 I concentrated on non security related mistakes. security will follow next week... :)
Re: AWS mistakes to avoid
#7You know what I've realized that's really important. More AWS tutorials is really needed. There's numerous of new programmers who want to learn AWS, but can't finish building anything because they get buried in documentation.
I find there are a lot of high-level abstracted tutorials, but for the new services, there aren't a lot of detailed tutorials.
For instance, an implemented cognito->gateway->lambda->dynamodb is really hard for a newbie to do.
Re: AWS mistakes to avoid
#8You know what I've realized that's really important. More AWS tutorials is really needed. There's numerous of new programmers who want to learn AWS, but can't finish building anything because they get buried in documentation. I find there are a lot of high-level abstracted tutorials, but for the new services, there aren't a lot of detailed tutorials. For instance, an implemented cognito->gateway->lambda->dynamodb is…
I found this series very helpful: https://medium.com/aws-activate-startup-blog
Re: AWS mistakes to avoid
#9My huge recommendation is to put production instances in a completely seperate region than development and staging instances. I actually just discovered that you can limit IAM API keys to a specific region, you just need to create a custom policy. The following policy is an example:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SOME-ID-HERE",
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Condition": {
"StringEquals": {
"ec2:Region": "us-west-2"
}
},
"Resource": [
"*"
]
}
]
}