Internet transfer taking ages for elastic beanstalk environment, with traceroute showing strange output - amazon-elastic-beanstalk

Question

I have an EBS environment set up in AWS us-east-1, and I'm calling it from Australia via http. There is a DNS set up in front of it on route 53, and I'm calling it via that. I'm aware that having the infra in us-east-1 should add some latency impact in terms of the internet speed.
However, the latency increase seems to be way more than normal. My analysis has shown that it takes 200ms for the endpoint to return a response, the response being 6000 characters of text, but then 900ms end-to-end for the data to hit my computer. That means the data transfer time over the internet is taking 700ms.
This latency is much less (about 100ms for data transfer) if i return for example just 20 characters. I've tried other endpoints in us-east-1 and they transfer the data a lot faster, so my internet connection is unlikely to be the issue. I tried doing a traceroute and here was the output. I'm not skilled at reading traceroute so im not sure if this is misconfigured:
1 mymodem (192.168.0.1) 5.515 ms 4.140 ms 4.416 ms
2 gateway.vb09.melbourne.asp.telstra.net (58.162.26.201) 13.920 ms 18.528 ms 14.207 ms
3 ae10.lon-ice301.melbourne.telstra.net (203.50.61.129) 15.245 ms
ae10.win-ice301.melbourne.telstra.net (203.50.61.145) 14.800 ms 13.342 ms
4 bundle-ether25.exi-core30.melbourne.telstra.net (203.50.61.128) 15.015 ms 15.545 ms
bundle-ether25.win-core10.melbourne.telstra.net (203.50.61.144) 15.603 ms
5 bundle-ether2.cla-core30.melbourne.telstra.net (203.50.13.124) 15.580 ms 15.727 ms 15.234 ms
6 bundle-ether19.chw-core10.sydney.telstra.net (203.50.13.144) 26.375 ms
bundle-ether3.hay-core30.sydney.telstra.net (203.50.13.132) 26.279 ms 27.283 ms
7 bundle-ether1.oxf-gw11.sydney.telstra.net (203.50.6.93) 25.961 ms
bundle-ether19.ken-core10.sydney.telstra.net (203.50.13.146) 26.221 ms 26.505 ms
8 203.50.13.98 (203.50.13.98) 27.733 ms
bundle-ether1.pad-gw11.sydney.telstra.net (203.50.6.61) 26.582 ms
203.50.13.98 (203.50.13.98) 26.650 ms
9 203.50.13.98 (203.50.13.98) 180.096 ms
203.50.13.90 (203.50.13.90) 26.194 ms 27.483 ms
10 203.50.13.90 (203.50.13.90) 165.233 ms 162.661 ms 163.185 ms
11 i-73.paix-core02.telstraglobal.net (202.84.247.45) 185.490 ms 181.710 ms 179.565 ms
12 i-92.paix02.telstraglobal.net (202.84.247.41) 180.893 ms
i-92.eqnx03.telstraglobal.net (202.84.247.17) 160.601 ms 161.498 ms
13 gtt-peer.paix02.pr.telstraglobal.net (134.159.61.98) 327.221 ms 183.915 ms
64.86.160.0 (64.86.160.0) 163.227 ms
14 ae11.cr7-dal3.ip4.gtt.net (213.200.115.26) 240.476 ms
ae12.cr7-dal3.ip4.gtt.net (213.200.120.106) 242.111 ms
64.86.160.5 (64.86.160.5) 220.202 ms
15 ip4.gtt.net (209.120.154.162) 213.780 ms 293.630 ms 308.845 ms
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
31 * * *
32 * * *
33 * * *
34 * * *
35 * * *
36 * * *
37 * * *
38 * * *
39 * * *
40 * * *
41 * * *
42 * * *
43 * * *
44 * * *
45 * * *
46 * * *
47 * * *
48 * * *
49 * * *
50 * * *
51 * * *
52 * * *
53 * * *
54 * * *
55 * * *
56 * * *
57 * * *
58 * * *
59 * * *
60 * * *
61 * * *
62 * * *
63 * * *
64 * * *
I also tried pinging the endpoint and got the following
.Request timeout for icmp_seq 240
If anyone could let me know if this is misconfigured or point me to what I should test/analyse to improve the data transfer latency that would be so useful.

Answer 1

There are indeed disturbingly many hops within Telstra's network! But Internet was designed to be resilient, rather than efficient.
AWS offers more optimal routing through its own private network with Global Accelerator, if your use case calls for a global service out of a single AWS region. Otherwise it may be cheaper to run replication across several AWS regions close to your users, and there are quite a few possible architectures with different tradeoffs between latency and cost, which will have to be considered in the context of your specific application.
Finally, to let the ping through to your instance, you will need to enable inbound rule for Custom ICMP - IPv4 traffic in your security group.