8

I built an ASP.NET MVC application, and now I want to move it to Amazon AWS from my development server. My question is: How does one migrate an ASP.NET application to Amazon AWS? Here is what I have researched/found so far:

  • Sessions don't work across instances, so I need to use DynamoDB or memcached to store state. I looked into various clients like Enyim as a possible solution to the session state problem using Amazon ElastiCloud.
  • Amazon has a web service for SMTP emails. So I will need to rework the code that sends SMTP emails to send through Amazon SES, and reroute incoming emails to a separate mail server by changing the DNS records.
  • There's an SDK for managing user identity (Amazon IAM). I will need to change the authentication code to use this web service.

Perhaps there are more points that I am unaware of. So, how does one migrate an MVC app to AWS?

arao6
  • 243
  • 2
  • 6
  • 1
    [Sharing your research helps everyone](http://meta.programmers.stackexchange.com/questions/6559/why-is-research-important). Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see [ask] – gnat Sep 07 '14 at 16:56

1 Answers1

4

Firstly, the things you're currently investigating would largely be the same regardless of whether you're taking your site from one machine to several (in-site) servers, to Azure, to Rackspace, etc.

When it comes to session state, your production site is now likely to run across several instances so will need to persist session data at a shared store so that user sessions can be loaded regardless of which server endpoint they end up hitting.

Dynamo could well allow you to handle colossal scale, but is likely to be a relatively costly. Depending on your expected (and eventually, real) traffic workloads, you may well be able to get away with a cheaper form of storage such as AWS Elasticache (especially since user sessions can be transient).

Modifying your SMTP handlers should be pretty trivial.

IAM is more about controlling users' access to AWS services.

What you've described is wanting to manage your own user accounts storage & access (via ASP.NET Membership?) - for that, a persistent relational storage mechanism like Amazon RDS.

There are plenty of examples of others who've done most of this - just GoogleBing it.

Other things to consider:

  1. I hope your site's doesn't require sticky sessions: this can make load-balancing a little tricky.
  2. Have you tested your app running across a couple of local instances, fronted with a simple load-balancer/proxy? It's easier to debug these things locally vs. in the cloud.
  3. You've not mentioned any form of back-end database ... I assume you've got your DB migration organized already?
Richard Turner
  • 426
  • 2
  • 4
  • Thanks, just in time! In fact, I am just about to move the app to AWS in the next two weeks (I created the question during the planning stage). It's an ASP.NET app with a MySQL backend. It uses SignalR for pretty much everything, so I think Elasticache is just what I need since SingalR supports Redis for a backplane. Thanks again! – arao6 Jan 28 '15 at 03:09