As a consultant that often recommends migration to AWS services for clients, this is a treasure-trove of information when looking at each individual use case and making a determination about how best to advise. It's often difficult to know with certainty whether AWS vs Google Cloud vs bare-metal is the best course of action, and the advice and information here goes a long way in helping make those decisions easier.
Open Guide to Amazon Web Services
51–60 of 133 posts
Re: Open Guide to Amazon Web Services
#52I have recently started out on AWS (I initially used AWS like I used to use Digital Ocean, however after trying out Serverless, I'm of a different mind and changing my ways to do it the AWS way), So this is pretty awesome!
Are you thinking dynamo for a backend, RDS, or other?
Dynamo for the backend
and ElasticCache (Redis) for some cache
Re: Open Guide to Amazon Web Services
#53Question to readers:
- What are your goals on AWS?
- What topic do you need help with? What articles would you like to be written?
Re: Open Guide to Amazon Web Services
#54The "use IAM roles for EC2" recommendation is a bit sketchy. The current security zeitgeist, not just after Colin's post but also after DerbyCon and Black Hat, is that EC2 roles are dangerous and, when under attack, not very predictable.
Using IAM roles for EC2 is far and away better than what beginners would otherwise do, which is create a set of permanent credentials and deploy it everywhere.
Re: Open Guide to Amazon Web Services
#55I recommend you also make the content available on a one-topic-per-page format ASAP before someone else does and takes credit for it. WHY: Google still doesn't handle anchor-links very well. You have 1000 amazing articles on a single page. Each section (e.g.: "High Availability on AWS") would be a great resource for someone searching on that topic in Google. But when you put it all on one page Google infers "1/1000th…
Why not both things? I like the monolithic format, but if the cost is lower SEO, maybe have a paginated version "in addition to" (as opposed to "in place of")
Yea, use the monolithic thing, and have the gh wiki have individual sections
Re: Open Guide to Amazon Web Services
#56Does anyone here use x1.32xlarge instances? If so what kind of stuff are you doing with it? That thing looks beastly
we use several of them for real time applications in adtech, and ML.
Re: Open Guide to Amazon Web Services
#57Thanks, I like that Service Matrix[1] ! I've a few questions for AWS experts : The only container orchestration that is open source seems to be Kubernetes. Is it easy to run on AWS? What's the equivalent of Azure "Service Fabric" in the AWS world? (and in the Google Cloud?) [1] https://github.com/open-guides/og-aws#service-matrix
We run Rancher[1], which is open source, across multiple AWS regions using a single ELB endpoint for container orchestration into different environments. You can use the stock AWS AMIs for the instances and Rancher also provides RancherOS AMIs that work extremely well.
Rancher also has k8s as an option and makes deploying it much easier.
Re: Open Guide to Amazon Web Services
#58Thanks, I like that Service Matrix[1] ! I've a few questions for AWS experts : The only container orchestration that is open source seems to be Kubernetes. Is it easy to run on AWS? What's the equivalent of Azure "Service Fabric" in the AWS world? (and in the Google Cloud?) [1] https://github.com/open-guides/og-aws#service-matrix
There are other open source container frameworks, we are using Aurora (http://aurora.apache.org/) but there is also Mesosphere (https://mesosphere.com/) and some other smaller ones...
Re: Open Guide to Amazon Web Services
#59Earlier quoted context omitted.
That's right. Instance store credentials have an expiration time of a few hours. However, if the instance policy is very open you could create yourself a new IAM account or use STS to maintain persistence after the generated credentials expire. This is why it's important to lock down instance profiles to do only what the application needs to do and no more. For example, you may give the permission to s3:DeleteObject,…
Thank you for the reply - that makes sense to me, least privilege seems to be the primary defense in that case. Having explicit creds you rotate yourself I could see having benefits as far as control, but also requires more work / potential for implementation mistakes.
Well, the AWS credentials auto-rotate. It does however provide a familiar place for an attacker to go to get the instance credentials, but that doesn't really help. At some point, those credentials must exist in plain-text for you to use them. If they're in a config file, they can be read out, if they're in RAM they can be pulled out with a debugger. At least if your box is temporarily owned due to a zero-day that you later patch, the credentials aren't going to be valid for long - although that situation would be hardly ideal!
You've also got to go to the trouble of getting the credentials on your box to start with. With instance roles, you can launch an instance and have it immediately capable of doing what your application needs. In the case of most applications my company runs, the instance profile is enough and no further security credentials are required. When database credentials are required, they're retrieved via S3, authenticated by the instance profile.