I'm setting up a TeamCity cluster, with an SVN server, in EC2, and want to user TeamCity's 'cloud' functionality to have it spin up new agents when needed.

My primary concern at this point is making sure that all communications between the three types of machines (TC Server, TC Agent(s), and SVN) user internal EC2 IP addresses to make the data transfers free (see the EC2 Pricing page, Availability Zone Data Transfer).

This is easy for the SVN server, I can put it's private IP address in to TeamCity Server configuration. However, for the TeamCity server URL, I believe I need to enter the external IP address so that users can access the server. The same IP address is sent to the newly spun agents so that they know where to talk to.

Therefore, communication from agents to server will be over the external IP, thus incurring data transfer costs. How do I avoid this?


I ran 'dig' on one of my agents, giving it hte elastic IP address of the TC Server, and got this (note I obfuscated the external IP slightly). No internal IP address is in there.

[ec2-user@ip-10-166-9-94 ~]$ dig 54.243.x.y

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.25.amzn1 <<>> 54.243.x.y
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60896
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;54.243.x.y.            IN  A

.           10800   IN  SOA a.root-servers.net. nstld.verisign-grs.com. 2012111500 1800 900 604800 86400

;; Query time: 38 msec
;; WHEN: Thu Nov 15 18:10:09 2012
;; MSG SIZE  rcvd: 106
  • Can you use a domain name instead of an IP? AWS instance DNS names will resolve to internal/external IPs correctly depending on whether or not you're in the AWS network.
    – ceejayoz
    Nov 6 '12 at 15:15
  • Not on the server itself, although I do on the apache instance fronting it. Seems like not a good idea though to route all the agent-server traffic through Apache though.
    – sharakan
    Nov 6 '12 at 15:18
  • I take it your suggestion would involve using Route 53 to make a new domain (or subdomain in our case), and assign that subdomain to the TC server. Then make serverURL point to that subdomain. And then when the agents call teamcity.mydomain.com/teamcity EC2 would map that domain to internal IPs?
    – sharakan
    Nov 6 '12 at 15:21

You don't need to setup a domain/DNS. If you assign Elastic IPs, you can use the Elastic IP Public DNS name, and it will resolve to the external IP if you query it externally, and resolve to the internal address if you query it from other EC2 instances.

So if I've got an Elastic IP of, the public hostname is ec2-54-254-54-54.us-west-2.compute.amazonaws.com. This will resolve to the internal IP if you query it internally.

You can CNAME your own hostname (foo.domain.com) to it, and it will function the same way.

  • OK, that would definitely resolve my problem. Is there anyway that I can confirm this is the case, perhaps with a command I can run from the shell or a chunk of code I can run?
    – sharakan
    Nov 7 '12 at 13:56
  • Sure, run a "dig yourpublichostnamehere" from an external host and compare the resulting IP to what you get running the same command from the ec2 instance. Nov 10 '12 at 5:31
  • Doesn't look like the external IP does resolve down. The result of running dig on a TC agent using the TC server external address doesn't refer to the internal EC2 IP address at all.
    – sharakan
    Nov 12 '12 at 20:05
  • When you say "TC server external address" are you using the IP or the DNS Name? Is your DNS name CNAME'd to the Elastic IP hostname or an A record pointing at the IP address? Nov 14 '12 at 6:12
  • In the dig query, I was using it's Elastic IP ip address, eg 54.243.x.y
    – sharakan
    Nov 15 '12 at 18:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.