I did find that DynDNS’s “free” service will let you setup 5 hostnames/ip addresses. Those hosts can be updated by an EC2 instance using something like ddclient. Of course querying those names from “outside” AWS would not provide a reachable address but for use between multiple servers inside AWS the name/ip mapping can make things easier. So doing this was like doubling my ElasticIP allotment on EC2 .

Your article highlights the issue well and provides some good paths to take.
Thanks.

I wholeheartedly agree – an AWS-managed DNS service would ease the pain.

If you find yourself running your own DNS inside AWS then you can minimize the risk of a DDoS and limit the scaling problem. You can use a separate domain name (or use a completely fake one, such as myapp.internal) and host this domain’s DNS in the cloud but leave the real public domain’s DNS outside the cloud. In this manner, the DNS server in the cloud need not have any public-facing services so it is not exposed to a DDoS attack. And it’s very unlikely that your application will outgrow the capacity delivered by a single (hefty) instance, though this can also be mitigated by tuning the TTLs. This technique does require your application to be written specifically to use the shadow/internal DNS domain or the public domain name, as appropriate for the circumstance, and (as mentioned in the article under “Dynamic DNS”) that the instances hosting your application be configured to use your own DNS server for the shadow/internal domain.

Of course this will only help if your service lives completely inside the cloud. If not, then you can outsource hosting both the public DNS and the shadow DNS to a service outside the cloud.

You have to register a DNS server with an IP right? ELB won’t work for DNS since you can’t give it a static IP, so I guess you could run your own ha-proxy in front of several mydns-ng boxes talking to a single mult-az RDS. Still, I think I’d rather pay a DNS provider that can more effectively deal with DOS attacks and get other benefits, like automatically pointing European users to your EU region if you have one. My vote is that it would be very helpful if Amazon added DNS to AWS.

The basic approach is the same regardless of whether you’re running a Windows or a Linux instance: you write some code that calls the EC2 API. This code can be a call to the EC2 command-line tools (which require Java on the instance) or a separate program that uses a library (such as boto for Python, or typica for Java) to directly call the EC2 API. The difference between Windows and Linux here is the way you register a hook to call this code at instance startup time. In linux you register a new “rc.d” script or put something into /etc/rc.local, depending on your linux distro. In Windows you create a new Scheduled Task.

For real flexibility you need to configure what Elastic IP address is to be associated with the instance, so each instance can have the same code (calling the EC2 API to associate the Elastic IP) but a different Elastic IP. One way to do this is to pass the Elastic IP address in via the user-data and have the code on the instance retrieve the user-data and fetch the Elastic IP address from there.

>hosting SMTP is more of a pain than DNS — I Agree.