clovis

I have two EC2 instances. EC2-A → client EC2-B (10.0.2.15)→ server running an app on port 8080 From EC2-A: curl http://10.0.2.15:8080 → works ✅ ping 10.0.2.15 → fails ❌ Security group is open for TCP 8080. Why does ping fail while curl works?

@SaibrousFarms Yes The request is taking too much time to reach Brazil

@clovistb #Latency The application server might be sitting right in 🇩🇪 with a fast latency through-put or responses of 80ms and 520ms in 🇧🇷 due to the above aforementioned…likewise, #Traffic #Distances 🇩🇪 > 🇧🇷 = Traffic Distances Covered I want to learn Snr.

Your application responds in 80 ms in Germany but 520 ms in Brazil. The backend is in Germany. The code is the same. So what’s causing the difference? How would you fix it?

@franknnabugo That is the multi region architecture

@clovistb Latency.. Your backend is hosted in server very far from users in Brazil.. To fix it, spin up an instance of your backend close to users in Brazil..?

@Osaaammma This is one solution

@clovistb Use a cdn

@xanderNLP 😆😆

@clovistb Delete the application.

@_jaydeepkarale I am curious to know how to move the users?

@clovistb Yeah, easy peazy

@Narender09_X @kritikakodes What is it?

@kritikakodes Vibe coding without 'skills' 😂

I am a Vibe coder, scare me with one word.🤔

@uday_devops Great approach 🙏

Geographic latency and the physical limitations of long-distance data transmission. - Use a CDN with edge caching using Cloudflare, for example. - Deploy a regional backend and run your app in AWS sa-east-1. - Use a global load balancer to route users to the nearest healthy backend automatically. - Place database read replicas in the region so the Brazil backend doesn't need to reach back to Germany for data.

@_jaydeepkarale Move the users? 😆

@clovistb Move the users to Germany

@CPUFXRnDMV What about multi region?

@clovistb That's easily network latency caused by routing and distance. Implement CDN caching (CloudFront or Cloudflare) and use DNS routing...aka Route 53. You should see much improved responses.

@_jaydeepkarale Destroy to build

Software Devs trying to look busy after managing to pass off a 1 pointer as 5 pointer

A tip for switching from IPV4 to IPV6👇

@aws_storm Yes 👍 It works perfectly

@clovistb Exactly for long term, however immediate fix would be add a mini CIDR block to meet the requirements and plan for IPv6 accordingly

I recently asked: “What would you do if your VPC is running out of IPs?” A lot of answers were: “switch to IPv6” Lets be clear: IPv6 is NOT a quick fix. Switching to IPv6 is a full transformation 👇 1️⃣Upgrade your network Routers, firewalls, load balancers, VPNs must support IPv6 2️⃣Redesign IP addressing IPv6 is huge, but you still need structure. Plan CIDR blocks (/56, /64) 3️⃣Validate OS & systems Your servers, containers, and nodes must support IPv6 4️⃣Enable IPv6 in cloud VPC, subnets, ALB/NLB must support IPv6 5️⃣Update DNS Add AAAA records. No AAAA = no IPv6 traffic 6️⃣Rethink security No NAT in IPv6 - Everything becomes publicly reachable - Rewrite firewall & security rules 7️⃣Fix your applications Update configs, APIs, DB connections 8️⃣Choose a transition strategy Dual-stack (most common) NAT64 / DNS64 IPv6-only (rare) 9️⃣Upgrade observability Logs, metrics, tracing must support IPv6. Many tools still assume IPv4 1️⃣0️⃣Test everything Connectivity, latency, failover, DNS. Expect surprises

@myonlinetrust @apparentorder IPv6 looks great but reality is still IPv4. most teams stay with dual-stack and NAT for now.

@apparentorder @clovistb I’ve been switching to IPv6-only (at least for public internet access), and doing *that* is kind of a pain. But if I was willing to set up a few NAT gateways (the expensive ones or just the cheap fck-nat ones) it wouldn’t be difficult.

@apparentorder still need CIDR expansion or better subnet planning for that.

Re. security, on AWS you can use the Egress-only Internet Gateway, which mimics the „security“ of a NAT Gateway (it does not allow inbound connections). Configuring dual-stack gets you two important wins very quickly and with low risk: provide IPv6 to end users (better experience) and use IPv6 for (some) egress traffic, saving potentially a lot of NAT traffic charges. Doesn’t help quickly with running out of VPC addresses though, admittedly.

@CPUFXRnDMV Thanks Derrick

@clovistb Great summation! 🤜🏾🤛🏾

Don't upgrade to IPV6 just for IP address exhaustion

@Guptha933907 Moving to IPV6 is a long process

@clovistb Exactly 👌 IPv6 solves address exhaustion, but introduces operational complexity. For most cases, CIDR expansion or secondary CIDRs are faster, safer fixes.

@shivamexec The app layer is the major part. It is where the work starts.

@clovistb Exactly, its been a while there are changes going on for various applications in our organisation to handle ipv6 from application before even starting to implement them

@Narender09_X Hahaha Good one