Skip to main content
Mohamed CamaraContact

East Freetown, Massachusetts

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.

The morning

Before I could see where it was going.

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.

That is the part I keep on this page. The rest of that morning, and the work that followed it, is written out here.

Bay State IT

I started on the helpdesk.

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.

  1. 01Someone calls with a symptom
  2. 02The machine in front of them
  3. 03The account they signed in with
  4. 04The path between here and there
  5. 05The server that was supposed to answer
  6. 06The place the file actually lives
  7. 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.

Open the full diagram

Landing zone drawn as paths along a single spineManagementAccountsIdentitySecurity boundaryTransit GatewayWorkloadsLog archive

Identity

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.

Read the lab data workflow

05

When mail and files and habits had to move

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.

  1. 01

    Ownership

    If I put my name on a design, I own what happens in operations too: certificates, integrations, drift, and handoff quality.

  2. 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.

  3. 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.

  4. 04

    Operational truth

    I trust evidence: logs, metrics, runbooks, and clear change history. Process should match how failures actually happen.

  5. 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.

  6. 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.