Browse through the questions and answers listed below or filter and sort to narrow down your results.
EC2 mysteriously loses connectivity - telnet google.com 80 not working - AMI on another EC2 works without problems
I have an ec2 instance on a public subnet with Ubuntu running for months without problems. Today, when connecting to it via ssh I have seen the following error: ``` Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings ``` Investigating a little more in depth I see that a simple ``` telnet google.com 80 Trying 184.108.40.206... ``` does not work, it does not establish a connection. I have also tried ``` nslookup google.com Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: google.com Address: 220.127.116.11 Name: google.com Address: 2a00:1450:4007:80d::200e ``` and it works fine. A telnet to another instance of the same vpc and subnet works ok. The systemd-resolved.service is up and without errors: ``` systemctl status systemd-resolved.service ● systemd-resolved.service - Network Name Resolution Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2022-08-23 10:37:22 UTC; 46min ago Docs: man:systemd-resolved.service(8) https://www.freedesktop.org/wiki/Software/systemd/resolved https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients Main PID: 1586 (systemd-resolve) Status: "Processing requests..." Tasks: 1 (limit: 4637) Memory: 4.3M CGroup: /system.slice/systemd-resolved.service └─1586 /lib/systemd/systemd-resolved Aug 23 10:37:22 ip-172-31-34-169 systemd: Starting Network Name Resolution... Aug 23 10:37:22 ip-172-31-34-169 systemd-resolved: Positive Trust Anchors: Aug 23 10:37:22 ip-172-31-34-169 systemd-resolved: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237> Aug 23 10:37:22 ip-172-31-34-169 systemd-resolved: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr> Aug 23 10:37:22 ip-172-31-34-169 systemd-resolved: Using system hostname 'ip-172-31-34-169'. Aug 23 10:37:22 ip-172-31-34-169 systemd: Started Network Name Resolution. ``` I have created an AMI of this instance and I have raised another ec2 with this AMI, and everything works correctly, the new ec2 is in the same vpc and subnet and has the same security group, so I rule out connectivity problems in the vpc, route table , ACL, internet gateway etc... Could it be due to some problem in the network interface? Any idea what could be happening?
Server lost connection, logs show ena5 connection issues
Our instance i-052cca656183d431d showed running but nothing could connect. I ended up stopping (let is try for 10 -15 minutes), then forcing to stop it (stopped roughly 5 min later), and once it came back up I saw network issues in the log right before it crashed ena: Reading reg failed for timeout. expected: req id offset actual: req id offset ena: Reg read32 timeout occurred systemd-networkd: ens5: Lost carrier systemd-networkd: ens5: DHCP lease lost and then a few minutes later no more logs until the reboot was successful. Is there an issue with Amazon network here? Thanks Jon
Network bandwidth performance
We have deployed 2 ec2 instances in same availability zone i.e. r5.2xlarge as per this instance features it has capability of up 10 GB network performance I'm confuse about its bandwidth calculation. Can someone give clarity on below points. 1. When it says up to 10 GB network performance is that mean it will give constant speed of 10GBPS.? 2. If I want to check maximum network bandwidth limit between 2 ec2 instances (Linux) how we can measure? Thanks in advance as this may help us for long term.
Internet ISP Network to AWS Jakarta
Hi, Today since noon at 15:00 Jakarta time. there are some user complaints that they can't connect to the ec2 server at aws jakarta. after seeing the problem there are some internet ISPs that can't connect while others can connect. example telkomsel internet provider ISP can connect while XL internet provider ISP can't connect. So the problem is who needs to take action to solve this problem? Thank You Hasan Wong
Lightsail CloudFront distribution returning an “X-Cache:Miss from CloudFront”
Hi All, I have successfully activated lightsail cdn then attached cPanel_WHM_for_Linux-2 and IP address with CloudFront. My CloudFront CDN is working fine. When I see my website header, it is showing “X-Cache:Miss from CloudFront”. How to rectify problem my URL is https://www.bismatrimony.com/ Note: My website is not wordpress it is php based site
Linux aws ec2 and Ubuntu t2.micro instances failed to update and install any software
I have launched today two Linux ec2 t2.micro instances and one Ubuntu t2.micro instances in us-west-2 region. All there did not either update the software or install java-11-openjdk. I have sent the complain to aws and they just gave me a like to the aws re:Post site. It was not my problem. I launched dozen of ec2 instances before and everything was OK. My home network was working fine. I was connected to the instances. The inbound and outbound security rules were set to accept HTTP traffic (TCP port 80 was open). ![I have attached a screenshot of the Ubuntu aws ec2, that failed to connect to archive.ubunty.com:80 and can not connet to security.ubuntu.com:80](/media/postImages/original/IMl_EasOC6QJa2I-sy1-bO5w)
systemd-resolved not forwarding dns requests to dns server when ElasticIP assigned
We have instances running ubuntu 20.04 which use systemd-resolved with a local address of 127.0.0.53 This appears to affect instances that have an ElasticIP assigned to them but not others. I cannot see any other difference. resolvectl status show that 10.0.0.2 is the dns server in use for both affected and non-affected instances. On affected instances, using tcpdump I can see that 127.0.0.53 is responding with SERVFAIL and not forwarding anythin to the Amazon DNS service, which is at 10.0.0.2 However if I manually send a request directly to 10.0.0.2 on affected instance: `nslookup x.y.com 10.0.02` it successfully perfroms dns request. Any ideas?
VPC is not working; Received 'No Proposal Chosen' error message
Scope: Created a static site-to-site VPC Customer: Watchguard Firewall with up-to-date software Problem: Used AWS instructions for watchguard and setup VPN Tunnel. 1. Checked and re-checked Phase 1 and Phase 2 settings 2. Checked that device can ping the AWS Public IP Address of the Tunnel 3. Checked that UDP Port 500 allows traffic through it The problem is that my remote site is not able to establish connection through the tunnel, in watchguard firewall logs i get the following error: ERROR 0x02030014 Received 'No Proposal Chosen' message. Check VPN IKE diagnostic log messages on the remote gateway endpoint for more information. Has anyone come across this?
Managing Route53 at scale
We have about 30 AWS accounts at this point (application, development, devops, shared services, sandboxes) and we are using AWS Control Towers tied into AWS SSO. We have recently created a designated networking account where we host the STNO solution and have decided this will be our centralized network traffic solution for all of our business needs. We are trying to figure out what the best practices are for managing DNS, private DNS zones in particular at scale. With using a central networking account, we can see the appeal of having all private zones in a single account so that we can get a complete picture of and monitor/manage the entire organization, but is this the current best practice? Will centralizing our private zones create problems for individual teams? For example, we want to give our Devs the ability to manage their private zone (dev.company.com) without allowing them to edit other zones. Is this possible with cross-account, centralized, private zones? Should we even allow our dev teams to manage their own private zone? If not, what is the current best practice for managing private zones within an org? Just hoping to get an idea of how other companies are managing this, what worked for previous clients, what didn't.
How to make HTTPS ALB that targets other TCP port of a fargate service?
I would like to make a HTTPS fargate service that is in a docker container with port 4000. I set up as follows. ``` Task definition/Port mapping of the container -Host port: 4000 -Container port: 4000 Target group -Target type: IP -Protocol: HTTPS (port 443) -IPv4 address: None Application load balancer -Listener protocol: HTTPS (port 443) -Default action: the TG above ECS service -Task definition: the definition above -Load balancer: the ALB above -Container to load balance: the container above -Production listener port: HTTPS (443) -Target group name: the TG above Route 53 A record -alias: the ALB above ``` However, when I access to the url of the A record, I got "503 Service Temporarily Unavailable" or "504 Gateway Time-out". I can access to the service if I do not use ALB and connect to the IP:4000 directly. What is the correct way to set up ALB and TG that connect to the container port 4000 via HTTPS?