You will get a new login page and username to log in with and not need an email address specific account.
http://docs.aws.amazon.com/IAM/latest/UserGuide/best-practic...
111–120 of 283 posts
You will get a new login page and username to log in with and not need an email address specific account.
http://docs.aws.amazon.com/IAM/latest/UserGuide/best-practic...
[Deleted]
Also having problem with AWS - can't access it and they keep billing me for something there I want to shut it down (EC2?) but I can't. I recently moved from Brazil to UK (new address) and changed phone + sim card (Authenticator after restore from backup lost all 2 factor auth entries). This is the moment when you realise that you're outside of predefined use cases of The Machine and you're fucked. Nobody is here to h…
I had 2FA activated, changed phones and lost it. I couldn't log in to my account, so I contacted support. Within about 30 min they had put me back into my account. The dude who helped me was super chill and understanding as well.
Earlier quoted context omitted.
In all seriousness, email jeff@amazon.com. The most likely outcome is that some relevant managers will receive one of the infamous "?" emails from him. If so, that'll result in two things: 1) Your problem will be resolved ASAP, managers right up the chain will be tracking it extremely closely, as they'll have to justify every action to Jeff. Everyone goes scrambling when one of those emails goes out. 2) A post-mortem…
I think that's gone the way of the dodo. Last I remember, he didn't read those anymore, and they were automatically just shunted into the normal escalation flow. Too many people got wind of it and abused it.
Earlier quoted context omitted.
By "self-host", don't you mean "rely on a landlord / ISP / colocation facility"?
Back in days we rented servers and created our env, it was not really that hard. And it was super easy to move from one provider to another.
As you do with AWS...
> and created our env
As you do with AWS...
> And it was super easy to move from one provider to another.
Which is easier on cloud hosting than it ever was when dealing with colocation providers.
Earlier quoted context omitted.
Because you're unlikey to trigger a violation on your cloud SaaS account, but could easily run afoul of other policies like "Real Name" or "Bought a Pixel Phone and Sold It" or posting something "offensive", getting reported by other users, etc. If the account is just for a cloud SaaS, then there's likely to be very few policies to disable your account.
But then you're storing passwords in more services, which creates more surface area for breaches. If you shop with Amazon, host your services with Amazon, watch TV on Amazon...there's simply no way of getting around the fact that Amazon will only want to manage a password for you in one place. The issue is clearly over reliance on Amazon services.
That's on you. You can't get the benifit of separation if you have them do it for you.
In the same way you get one company to own your domain and one to run your email. That way when your email provider decides you're a spammer or your account get's closed for uploading a bad app to the android store, you can go else where and swap your dns.
Any references to how one should go about separating an Amazon retail account and an AWS account, if they are presently the same?
CloudFormer[0] might be able to automate some of the process - it analyzes your existing VPC and generates a CloudFormation[1] template. You could then take this template and deploy the stack in your new account, and you'd only have to rebuild the remaining few items.
Then you could redeploy all your applications, test, and migrate production services to your freshly-tested instance. Finally, you must be aggressive in shutting down the old services. It would be agonizing to have your entire site down because one server remains in the old account, and the account had some issue. Feel free to contact me for more specific advice.
[0] https://www.linkedin.com/pulse/how-why-use-aws-cloudformer-a...
[1] https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...
[Deleted]
I am incredibly happy that Digital Ocean made you go to those lengths to get your account back. The last thing we need is web services companies requiring less security. Social engineering attacks are typically the method of entry to hosting providers such as Digital Ocean.
Frankly I would be totally fine if they required another form of ID (such as a passport) or another form of address/name verification (such as a utility bill). Or perhaps even a picture of the card on file.
What is NOT okay is a lack of response, which this article is describing.
8 days ago I tried to log in to my Amazon retail account, and received a password invalid error. As it turned out my account had been closed, as it appeared to Amazon that it had received a suspicious log in. This is the same account that I use for AWS - hosting websites critical to my business. Today it appears I am no closer to gaining access back to my AWS account than I was on day 1, even though I have been bille…
This happened to me with instagram. I reset a password, then they detected "suspicious activity." I clicked "send pin via email" and the email never shows up. I've done it 3 or 4 times over the course of a week + it never works. It's a documented error + FB/Instagram refuse to addres it. https://medium.com/@joelrunyon/instagrams-security-features-...