[Quick Bites] Common Services

Gauransh Mathur

Gauransh Mathur

— 3 min read
Share
[Quick Bites] Common Services
This is part of my enterprise cloud architecture series.

In simple systems you probably don't know all of these services, or you have no need for them. You use the default IAM policies, you encrypt and manage your own keys, and certs are self served. You have your own trust boundary, so you never look into KMS or IAM roles in a granular form.

An enterprise is different. Certs have real rotation, data has proper encryption at rest, and IAM policies are written out in granular JSON.

What are common services?

They are called common because they are always used in any infra deployment. Your architecture might change from EC2 to ECS to EKS to Lambda, but these services are still needed.

Where do they fit?

ServicePurposeWhere it is needed in an enterprise deploymentWatch out
ACMCertificate managementTLS certs on the load balancer and CDNImported certs you renew yourself, CloudFront certs have to be in us-east-1
IAMRBACA role per workload, scoped to the resources it touchesRoles over long term access keys
KMSEncryptionKeys behind encryption at rest for S3, EBS and RDSThe key policy has to allow access too, IAM alone is not enough
Secrets ManagerSecret managementDatabase credentials the app reads at runtimeRotation is built in, Parameter Store does not have it
Route 53DNS resolution, public and privatePublic zone for the company domain, private zone for internal names in the VPCA private zone only resolves from the VPCs attached to it
CognitoAuthentication, SAML and OIDCApp user sign in through the company identity providerUser pools authenticate, identity pools give out AWS credentials

Least privilege

Least privilege is to only allow a specific role to a specific resource. It narrows everything down to the work a service role needs to do.

How do they connect?

Some connect, some don't. ACM validates a certificate with a DNS record, and that record goes in the public Route 53 zone, a private zone can't be used for it. Secrets Manager encrypts what it holds with KMS. Cognito identity pools hand out IAM roles to signed in users, and IAM sits under all of them. Route 53 is the one that stands alone.

Who looks after what?

AWS looks after the actual infra, the real servers. The customer manages on top of the service they are hosting, like the configuration inside each service.

Why so many?

Each one has its own purpose. They are AWS specific because they fit into the AWS vs customer boundary of who maintains security. Except for Route 53, all of these are security management tools.

There are no cloud agnostic alternatives to name, as they only matter for the account they are in, to allow a secure deployment. Moving to another cloud would still use that cloud's own security tools.

Where it gets hard

The difficulty is configuration and management, there is a lot of overhead to remember and manage. It is 50 IAM roles and configurations. It is cert rotation for every microservice you have in EKS, with public cert validity dropping to 200 days now, 100 days in 2027 and 47 days in 2029. It is secrets for VM passwords, making sure they are rotated but not leaked.

Next up: Gateways

Read more