Mohamed CamaraBuilt from helpdesk to architecture.
I work on AWS foundations, hybrid networks, identity, and the systems around them. I started on the helpdesk, with the person who had a problem in front of them.
There was a time in my life when everything felt uncertain. Not the kind of uncertainty you can easily ignore, but the kind that sits with you quietly and follows you throughout the day.
I sat by the window. The sky was still dark, but you could tell something was about to change. Slowly, almost quietly, the first light started to appear.
Progress doesn't always feel like progress when you're in the middle of it. Just because you can't see the full picture yet doesn't mean nothing is happening.
I didn't need everything to be perfect before moving forward. I didn't need to have every step figured out. What I needed was to keep going, even when things weren't clear.
At Bay State IT I was not thinking about architecture. I was trying to understand why something that worked yesterday had stopped working today.
People called with what they could see. A login that failed. A file that was not where it had been. A machine that was fine until it was not. I got interested in the cause.
The ticket was never the whole problem.
A call starts at one machine. Stay with it and it keeps opening into the system around that machine.
01Someone calls with a symptom
02The machine in front of them
03The account they signed in with
04The path between here and there
05The server that was supposed to answer
06The place the file actually lives
07The cloud the rest of it sits in
What the work turned into
The system, as I met it.
These are not a list of skills. They are the parts of an environment that became my responsibility as the work got larger.
AWS
Control Tower, Landing Zone Accelerator, multi-account estates.
I ended up here when a single account stopped being something you could keep in your head. The work became an estate someone new could map.
The same line
As the environments grew, so did the responsibility.
A healthcare landing zone
What that responsibility looks like.
A multi-account AWS foundation I deploy and operate, aligned to HIPAA and HITRUST. Choose a layer. The drawing follows it.
Microsoft Entra ID over SAML, SCIM provisioning, permission sets, MFA, and Client VPN. One place to grant access, and one place to take it back.
Evidence
Systems I have lived inside.
Not a catalog. Environments I stayed in long enough to know where they break. On a wide screen, move through them sideways.
01
When the AWS footprint outgrew one account
I have helped teams move from ad-hoc AWS sprawl to clear multi-account foundations. The real goal is an estate a new engineer or auditor can map without guesswork.
Reduced identity onboarding from days of manual IAM work to same-day provisioning via IAM Identity Center and SCIM. New engineers reach the right accounts in under an hour.
Same dayA new engineer could reach the right accounts the day they started, instead of waiting on manual IAM.
02
Lab and research stacks that had to behave like production
ParallelCluster and Slurm environments where failed jobs mean lost science, not just lost time. I treat these stacks as long-term platforms, not temporary grant artifacts.
Rebuilt a Slurm cluster that had been losing jobs to misconfigured memory limits — zero job failures in the 6 months after cutover. The team stopped tracking cluster state manually.
6 monthsNo job failures from the memory limits that had been dropping work before the cutover.
03
The stretch between cloud and everything that could not move
Hybrid connectivity across VPN, Transit Gateway, and routing paths that stay legible under pressure. I prefer explicit maps over hidden assumptions.
Replaced a flat VPC-per-account mesh with a Transit Gateway hub — cut routing table sprawl by ~60% and gave the network team a single choke point for east-west inspection.
~60%Less routing-table sprawl once the mesh became a Transit Gateway hub.
04
Access, data, and what survives a bad day
Identity, storage, and DR work that aligns access and recovery with reality. A plan is only credible if someone has practiced it.
Ran the first live DR failover test the organization had ever attempted — completed in under 4 hours with no data loss. The runbook that came out of it replaced a document no one trusted.
Under 4 hoursThe first live disaster-recovery test they had run. It finished clean, without data loss.
Workspace-to-M365 migrations including tooling, DNS, and identity cutovers. I stay through stabilization, because that is where trust is earned.
Migrated ~200 mailboxes over a single weekend with zero rollbacks and one support ticket — a shared drive naming conflict caught in pre-flight that would have taken days to untangle post-cutover.
200Mailboxes moved over a weekend. No rollbacks. One ticket, caught before cutover.
06
Honest reads on what the estate is really doing
Architecture and risk reviews aimed at better sequencing, cleaner spend, and fewer operational surprises. I call out delivery gaps early when promises outrun platform reality.
A cost review surfaced $40k/year in idle reserved instances and orphaned snapshots across three accounts — found in the first pass, paid back the engagement inside 30 days.
$40kA year of idle instances and orphaned snapshots, across three accounts, on the first pass.
Field notes
What I kept.
Nothing here arrived as a slogan. It is what I started doing after I had been wrong, or late, or unclear.
01
Ownership
If I put my name on a design, I own what happens in operations too: certificates, integrations, drift, and handoff quality.
02
Clarity for every audience
Engineers need specifics, and non-engineers still need clear trade-offs. I aim for language both groups can act on.
03
Security and scale as engineering
Security and scale are design decisions, not late-stage add-ons. It is always cheaper to argue in design than in incident review.
04
Operational truth
I trust evidence: logs, metrics, runbooks, and clear change history. Process should match how failures actually happen.
05
Promises you can keep
What is sold and what the platform can sustain should describe the same reality. I push back when that gap grows.
06
Writing for the next person
Documentation is part of delivery. Good notes and diagrams are how you respect the next operator and your future self.
Still unfinished
Still rising.Still becoming.
The work tends to be an AWS foundation, a hybrid network, identity, research computing, storage and recovery, or a move to Microsoft 365 that has to be quiet on Monday morning.
If something here connects with what you are working through, write to me.