Master's thesis idea around encryption key management

Hi
I finished my university some years ago but I need to finally write my master thesis. I need to present idea what should I write about so I need to ask here because I don't have supervisor available now.

Now I have idea to write about: cryptoperiods, key rotations and that a rotated KMS key has an infinite cryptoperiod, while CIS/Prowler/AWS Config all report it as compliant because they only check a boolean flag that key is rotated.
My thesis would build a tool that infers actual cryptoperiods from CloudTrail and S3 Inventory instead of config, flags ciphertext still stranded on retired key versions, and generates a re-encryption plan to close the recipient-usage period.

Does this hold up, or am I missing something obvious? And is it master's thesis level or not? Maybe someone has other idea around this key management and cloud topic.

reddit.com
u/Old-Astronomer3995 — 6 days ago

Master's thesis idea around encryption key management

Hi
I finished my university some years ago but I need to finally write my master thesis. I need to present idea what should I write about so I need to ask here because I don't have supervisor available now.

Now I have idea to write about: cryptoperiods, key rotations and that a rotated KMS key has an infinite cryptoperiod, while CIS/Prowler/AWS Config all report it as compliant because they only check a boolean flag that key is rotated.
My thesis would build a tool that infers actual cryptoperiods from CloudTrail and S3 Inventory instead of config, flags ciphertext still stranded on retired key versions, and generates a re-encryption plan to close the recipient-usage period.

Does this hold up, or am I missing something obvious? And is it master's thesis level or not? Maybe someone has other idea around this key management and cloud topic.

reddit.com
u/Old-Astronomer3995 — 6 days ago

IT consulting and technical newsletter for engineers

Hi
Im cloud architect looking for B2B clients for migrations audits, applications etc.
I have a lot of traffic from my technical posts about technologies that I work with from Pages like Reddit, hackernews. Of course these people are mainly engineers that wants to read about other technical stuff. Question is if it makes sense for me to build newsletter for that to somehow use it and inceease returning people to my blog or better to not spend time on that? My thinking process is that with better brand awareness maybe someone will recommend me in their company when there will be a need? I don't have idea how to get emails from company owners and for now traffic from engineers is much bigger.
Has anyone here experience with this kind of company leads generation?

reddit.com
u/Old-Astronomer3995 — 26 days ago

IT consulting and technical newsletter for engineers

Hi
Im cloud architect looking for B2B clients for migrations audits, applications etc.
I have a lot of traffic from my technical posts about technologies that I work with from Pages like Reddit, hackernews. Of course these people are mainly engineers that wants to read about other technical stuff. Question is if it makes sense for me to build newsletter for that to somehow use it and inceease returning people to my blog or better to not spend time on that? My thinking process is that with better brand awareness maybe someone will recommend me in their company when there will be a need?
Has anyone here experience with this kind of company leads generation?

reddit.com
u/Old-Astronomer3995 — 26 days ago
▲ 77 r/cpu+1 crossposts

Kubernetes CPU throttling: why a pod at 40% CPU can still get throttled (CFS)

Disclosure: I'm affiliated with RoszigIT, where this article is published. Sharing because the mechanics are worth discussing, not to pitch anything. I tried to make it technical as always.

  • Pod can have 40% cpu usage in metrics and still have performance issues
  • How a burst that uses all 4 cores can exhaust a whole period's quota in 50ms real-time, freezing the container for the remaining 50ms — invisible on an averaged CPU graph
  • Where to actually look: nr_throttled / throttled_usec in cpu.stat, plus why PSI (cpu.pressure) and hypervisor steal time (%st) catch different failure modes that cpu.stat misses entirely

https://roszigit.com/en/blog/kubernetes-cpu-throttling/

u/Apprehensive-Buy7455 — 28 days ago

Research topic: Kubernetes overhead

Hi
I'm looking into a new topic for research. My career is focused around Kubernetes so I look into something related to that. I found out that there is not too much articles about Kubernetes overhead in comparision to bare metal non-containerized worklad - but maybe there is a reason why no one does this?
I thought about doing a measurements with bare metal, then just container spawned by conteinerd, then on full kubernetes node with latency measurements p50/p99/p99.9/max and requests per time or something similar. So to verify which components impacts performance.

Similar like in this paper from 2014 that is very popular but old one: https://scispace.com/pdf/an-updated-performance-comparison-of-virtual-machines-and-51dkcxz9au.pdf

There is some similar paper but a very simple one without checking which linux components impacts performance: https://researchspace.csir.co.za/server/api/core/bitstreams/62bc33e5-386c-4c67-9fcd-87c6a1194948/content

What do you think? Does it make sense to work on that? Maybe there is something that I'm missing or should look into that from a different angle?

reddit.com
u/Old-Astronomer3995 — 1 month ago

Research topic: Kubernetes overhead

Hi
I'm looking into a new master thesis topic. My career is focused around Kubernetes so I look into something related to that. I found out that there is not too much articles about Kubernetes overhead in comparision to bare metal - but maybe there is a reason why no one does this?
I thought about doing a measurements with bare metal, then just container spawned by conteinerd, then on full kubernetes node with latency measurements p50/p99/p99.9/max and requests per time or something similar.

Similar like in this paper from 2014 that is very popular but old one: https://scispace.com/pdf/an-updated-performance-comparison-of-virtual-machines-and-51dkcxz9au.pdf

There is some similar paper but a very simple one without checking which linux components impacts performance: https://researchspace.csir.co.za/server/api/core/bitstreams/62bc33e5-386c-4c67-9fcd-87c6a1194948/content

What do you think? Does it make sense to work on that? Maybe there is something that I'm missing or should look into that from a different angle?

reddit.com
u/Old-Astronomer3995 — 1 month ago

Why Postgres TOAST does almost nothing for time-series, and what TimescaleDB does instead (disclosure: my company blog)

Disclosure: I'm affiliated with RoszigIT, where this article is published. Sharing because the mechanics are worth discussing, not to pitch services. Tried to make it as technical as possible

A walk through what actually happens to your rows when a chunk gets compressed. REAL example from production application.

The counterintuitive part most people miss: for typical time-series queries compression makes them faster, not slower, because it cuts I/O 10–20×. It only hurts on point lookups, UPDATE/DELETE on compressed chunks, and queries that don't filter on your segmentby column when that column is high-cardinality.

  • How a chunk is converted: ~1000 rows are grouped into a single row in the compressed table, where each column becomes an array (column-major inside the batch).
  • Why the ratio varies wildly by schema — the algorithm is chosen per column type: delta / delta-of-delta + simple-8b + RLE for ints and timestamps, Gorilla-style XOR for floats, dictionary (+ TOAST fallback) for JSONB. A per-row UUID compresses terribly for the same reason a regular-interval timestamp drops to near-zero bytes.
  • Why TOAST (vanilla Postgres) does almost nothing here: it compresses individual oversized values, not cross-row patterns, so it's ~1.0× on the float/timestamp columns that dominate time-series.
  • segmentby / orderby — the two parameters that decide everything. segmentby is stored once per batch and lets the planner skip whole batches via an auto-built sparse minmax index on (segmentby, _ts_meta_min, _ts_meta_max). Point it at a high-cardinality column (e.g. sensor_id with thousands of sensors) and your batches underfill — encoders need ~100+ similar rows per segment or the ratio collapses.
  • A real before/after: same point-read-by-id query went 42.8× smaller on disk and ~28× faster in execution on a columnstore chunk. Caveat I put in the post: 42× is my MQTT dataset (unusually redundant); realistic for typical time-series is 8–20×.

https://roszigit.com/en/blog/timescaledb-compression-hypercore/

u/Old-Astronomer3995 — 2 months ago

Kubernetes CPU requests and limits, explained through cgroups (disclosure: my company website)

Disclosure: I'm affiliated with RoszigIT, where this article is published. Sharing because I think the mechanics are worth discussing, not to pitch services. I tried to make this post as technical as possible.

An argument for when CPU limits are worth the throttling cost (multi-tenant clusters, untrusted workloads, managed services like ECS that require them, cost control) and when they're probably hurting you (single-tenant clusters you control, bursty workloads where throttling adds latency for no real isolation benefit).

The post walks through what actually happens in the kernel and cgroups when you set CPU requests and limits in a pod spec.

  • How requests.cpu is converted to cgroup shares (v1) / weight (v2) via MilliCPUToShares — the milliCPU * 1024 / 1000 formula — and how the Linux scheduler distributes CPU time proportionally to those weights only when there's actual contention.
  • How limits.cpu maps to the CFS bandwidth model (cpu.cfs_quota_us / cpu.cfs_period_us) via MilliCPUToQuota, with the default 100ms period, and what throttling actually looks like at the kernel level.
  • Why setting cpu: 1500m doesn't mean "1.5 cores" — it's a weight ratio, not an allocation.

https://roszigit.com/en/blog/kubernetes-cpu-request-limit/

u/Old-Astronomer3995 — 3 months ago

Hi

I wrote article about Kubernetes limits and requests where I'm describing how it works from cgroups and cpu controller level. I need a few experienced people to give me feedback. I don't want to promote so I will send URL in DM. Anyone interested?

No AI slop. I swear.

reddit.com
u/Old-Astronomer3995 — 3 months ago
▲ 1 r/aws

Hi
I think I'm correct and my ticket according to AWS support plans comparision should be assigned in less than 24 hours for billing question with support 24/7. I’ve been waiting for over 13 days, and my ticket is still unassigned. Are there any known delays or issues with support response times recently? I don't understand what's happening.

reddit.com
u/Old-Astronomer3995 — 4 months ago