By using AWS re:Post, you agree to the Terms of Use

Learn AWS faster by following popular topics

see all
1/18

Recent questions

see all
1/18

EC2 outbound bandwidth dropped on July 21st and stays very low (eu-west-1)

Hello, In our organization, we run our CICD using gitlab. We spawn runners on demand and each runner is a EC2 instance. Since July 21st, the uploads performed by these runners got their duration multiplied by ~10. From our tests, we see that: - outbound bandwidth from any instance type and any AMI we can spawn in eu-west-1 is now <2,5Mb/s (~300KB/s), - we tested t3.medium and m6a.large, - we tested various AMIs (ubuntu, amazon linux), - this seems far from any quota/limit/advertised bandwidth, - before July 21st, it was around 25Mb/s (~3MB/s) for t3.medium runners, - download speed is 500Mb/s, - upload/download target is the gitlab server host itself, - located in Paris, - can be reached through 2 different physical connections and we get very good speed from other places, - all speed tests mentioned here are performed using iperf3, - runners are in a VPC, routed through an Internet Gateway, - if we spawn a runner in eu-west-3, outbound speed is 24Mb/s (and download is 1Gb/s), - that's not great, but at least it’s 10 times what we get in eu-west-1 (and close to what we had before “the incident”). - we haven’t changed a thing regarding our configuration, runners, gitlab version, code. The problem happened suddenly for pipelines run after July 21st, 4pm cest, We may consider spawning our runners in eu-west-3, or even move our gitlab server on EC2, but since 1) the problem happened suddenly without any action on our side and 2) this would require moving other resources as well, time, effort and cost, we’d rather prefer a logic explanation of what’s happening here before taking actions. We are looking for clues to understand: - how to monitor this in order to identify if we actually reach a limit/quota, - why this changed suddenly, - why outbound bandwidth is that low (is that to be expected, or not). Any help investigating would be greatly appreciated! Best,
0
answers
0
votes
6
views
asked 2 hours ago

AWS VPN Client can not be connected.

AWS VPN Client can not be connected with below logs. ``` 2022-08-10 13:21:44.518 +09:00 [DBG] CM processsing: >LOG:1660105304,I,open_tun 2022-08-10 13:21:44.518 +09:00 [DBG] CM processsing: 2022-08-10 13:21:44.518 +09:00 [DBG] 🥶 APPEND line 2022-08-10 13:21:44.518 +09:00 [INF] Begin receive init again 2022-08-10 13:21:44.521 +09:00 [INF] Received bytes: 105 2022-08-10 13:21:44.521 +09:00 [DBG] Message marshalling complete 2022-08-10 13:21:44.521 +09:00 [DBG] CM received: >LOG:1660105304,,CreateFile failed on TAP device: \\.\Global\{5B0DB356-AB62-485C-A071-3537D307D3BB}.tap 2022-08-10 13:21:44.521 +09:00 [DBG] CM processsing: >LOG:1660105304,,CreateFile failed on TAP device: \\.\Global\{5B0DB356-AB62-485C-A071-3537D307D3BB}.tap 2022-08-10 13:21:44.521 +09:00 [DBG] CM processsing: 2022-08-10 13:21:44.521 +09:00 [DBG] 🥶 APPEND line 2022-08-10 13:21:44.521 +09:00 [INF] Begin receive init again 2022-08-10 13:21:44.521 +09:00 [INF] Received bytes: 151 2022-08-10 13:21:44.521 +09:00 [DBG] Message marshalling complete 2022-08-10 13:21:44.521 +09:00 [DBG] CM received: >LOG:1660105304,F,All TAP-Windows adapters on this system are currently in use. >FATAL:All TAP-Windows adapters on this system are currently in use. 2022-08-10 13:21:44.521 +09:00 [DBG] CM processsing: >LOG:1660105304,F,All TAP-Windows adapters on this system are currently in use. 2022-08-10 13:21:44.521 +09:00 [DBG] CM processsing: >FATAL:All TAP-Windows adapters on this system are currently in use. ``` I reinstalled the VPN Client but the error occurs continuously. Raptop brand is Lenovo and OS is Windows. How should I correct this error?
0
answers
0
votes
5
views
asked 2 hours ago
0
answers
0
votes
6
views
asked 4 hours ago

WorkSpaces freezing upon WorkSpaces Client screen resize

Has anyone else had issues with WorkSpaces freezing upon dragging to resize the client? I have had this at multiple clients with multiple unrelated AWS environments. Doesn't matter what version of the Amazon WorkSpaces Client software you use. Basically, what happens is: 1. You log on, let's say with the WorkSpaces Client for Windows. Everything is fine. 2. You drag the edge of the WorkSpaces Client to make the window of the application larger, OR let's say you go to Full Screen mode. 3. The client simply freezes. The desktop does not immediately resize, OR the screen goes black. 4. It stays frozen for about 5 mins, then magically the resize "catches up" and everything settles down and goes back to normal. 5. It also happens if you use a zero client, but the WorkSpace was previously running in the WorkSpaces Client software (and sized for the client it was running on) and thus needs to resize again to fit the zero client. Or vice versa. Hope I'm explaining this properly. It does not happen on all WorkSpaces at all times. There does not even need to be any applications open. However, when it does start to happen on a particular WorkSpace, it is very repeatable on that WorkSpace for a considerable amount of time (like all day, or occasionally all week). Multiple reboots and it still recurs. Then on another day it might not do it at all, and resizes work fine on that same WorkSpace. I can't think of any common denominator that these WorkSpaces have. Maybe ScreenConnect? Incidentally, if you view the desktop through ScreenConnect while this is happening, it remains “stuck” - you click on things, nothing happens - you can't really interact with it…but you *can* connect to it. Interestingly, it does not disconnect the session. And if you send a reboot command it immediately restarts the WorkSpace, so it is still "alive" so to speak. I'm curious to hear if anyone else has run into this. Thanks!
0
answers
0
votes
4
views
asked 9 hours ago

Recent articles

see all
1/8