AWS Cloud Setup in India (2026)

A VPC is an address plan before it is a network. We choose a range that cannot collide with the office LAN, the plant network or anything a future acquisition might bring, then carve it into tiers per availability zone. A /16 for the environment with /20 or /24 subnets leaves room to grow, and renumbering later is the sort of project nobody budgets for.

Three zones, three tiers. Public subnets hold only the load balancer and the NAT gateways, the pieces that must touch the internet. Application subnets sit private, reachable from the balancer and from a session tool that removes the need for a jump host. Data subnets have no route to the internet at all, which is a stronger statement than a security group rule and far easier to audit.

The NAT decision is where budgets diverge. One gateway shared by every zone costs a single hourly charge and looks tidy on a diagram, but traffic from the other two zones crosses an availability boundary and is billed for the privilege, and a zone failure takes outbound access with it. One gateway per zone triples that hourly line and removes both problems. For production the second option is almost always correct; for a development account a single gateway is a fair compromise, provided somebody wrote down the trade.

VPC endpoints deserve the same honesty. Gateway endpoints for S3 and DynamoDB add a route and cost nothing, so they go in on day one. Interface endpoints are charged per endpoint per zone with a processing component, which makes them a calculation rather than a default. Heavy use of Systems Manager, ECR or CloudWatch Logs usually justifies them; an endpoint for a service nobody queries simply adds another line to the invoice.

Security groups carry the stateful, resource-level rules. Network ACLs stay coarse and stateless, reserved for the rare subnet-wide block, because expressing a full application policy in ACLs produces something no one can read at three in the morning.

Two VPCs that need to talk should be peered. A peering connection has no hourly attachment fee, carries traffic across the AWS backbone and takes minutes to create. Its limits show up later: peering is not transitive, so a third VPC means a third connection, and the route tables multiply faster than the diagram does.

Transit Gateway becomes the better answer when the count climbs or when a shared services VPC has to serve several environments. It charges per attachment per hour plus per gigabyte processed, and it buys transitive routing, separate route domains and one place to attach a VPN or Direct Connect. For a two-VPC estate that attachment bill is hard to justify against a free peering link; at five or six VPCs with shared egress, the arithmetic starts to favour the hub.

PrivateLink answers a different question. It exposes one service, a listener behind a network load balancer, to a consumer through an endpoint in their own VPC, without either side learning the other's address range. Overlapping CIDRs stop being a problem, the connection is one-way by construction, and the consumer never receives a route into your network. It is charged per endpoint per zone plus data, so it suits a partner API or a vendor integration rather than general east-west traffic. The full decision tree, including the CIDR and routing traps that break each option, is in the Transit Gateway, peering and PrivateLink comparison. When a client insists that no CIDR be shared, PrivateLink is usually the only clean answer.

A site-to-site VPN is the sensible first hybrid link. Two tunnels terminate on a virtual private gateway or a transit gateway, BGP advertises the routes, and the connection exists the same day. It runs over the public internet, so latency moves with the ISP and throughput is bounded by the tunnel, but for directory replication, database seeding and administrative access that is normally sufficient.

Direct Connect is a physical circuit ordered through a carrier and cross-connected at a partner location. Lead time runs from several weeks to a few months depending on the last mile, and the bill has a port charge, a carrier charge and data transfer on top. What it buys is predictable latency, committed bandwidth and a path that does not share congestion with office broadband. A single circuit is still a single failure, so a serious design pairs it with a VPN backup or a second circuit on a different path.

The sequence that works for most first workloads: prove the application over VPN, measure what actually crosses the link for a month, then order Direct Connect if the numbers justify it. Ordering fibre before the workload exists tends to produce an expensive circuit carrying overnight backups.

Identity quietly determines the blast radius of every mistake. Root is locked away. People sign in through IAM Identity Center or the company's own identity provider, receive permissions through groups, and use temporary credentials. Machines assume roles: an instance profile for EC2, an execution role for Lambda, an OIDC trust for the CI system. Long-lived access keys are treated as an exception that needs a reason and a rotation date.

A permission boundary is an IAM policy that caps what another policy may grant. Attach one to a role and that role can hand out permissions only inside the boundary, even if it also holds AdministratorAccess. That is how a team lead can create roles without being able to create one that reads every bucket in the account. The boundary grants nothing by itself, and one written once and never reviewed is a false sense of safety.

Service control policies sit a level higher, in AWS Organizations, and apply to whole accounts. They can deny a region, block public buckets or prevent CloudTrail from being switched off, and they override every IAM policy inside the account. The trade is real: SCPs need an organisation, they bind future teams too, and an over-broad deny has caused more than one outage. In a single-account build there is nowhere useful to put them, so boundaries, tight roles and IAM Access Analyzer do the work. In a multi-account estate they become the primary guardrail.

CloudTrail's event history shows ninety days of management activity and then forgets it. A trail writes the same events to S3, which is what an investigation six months later actually needs. Whether that trail is an organisation trail or a per-account trail matters more than it appears: an organisation trail lands every account in one bucket with one retention rule, and a member account cannot quietly disable it. A per-account trail is simpler to start and becomes a reconstruction job the day a second account appears.

Even with a single account, putting the log bucket in a separate account is worth the extra work, because a stolen key in the workload account then cannot delete the evidence of its own use. Log file validation and object lock close most of the remaining gap.

GuardDuty watches for behaviour: cryptocurrency mining, credential use from an unusual country, reconnaissance against the instance metadata service. It produces findings rather than a stream of raw logs. Config records resource changes and evaluates rules such as encrypted volumes, public S3 policies and root MFA. Security Hub collects both and scores them against a standard, which is useful mainly because it gives one list instead of four consoles. All three bill by volume of activity, so switching everything on without a retention plan is how a security programme turns into a cost review.

WAF sits in front of CloudFront, an application load balancer or API Gateway and inspects requests before they reach the application. AWS managed rule groups give a maintained baseline against common injection and bad-bot patterns within an afternoon. Their weakness is that they are generic, and a rule that protects a blog can reject a legitimate upload. We enable them in count mode first, read what they would have blocked, and only then switch to blocking.

Custom rules do the work the managed groups cannot: a rate limit per address, a challenge on the login path, a block on a country you do not serve. Each rule is a maintenance item, and WAF charges scale with rule count and request volume, so a long list of half-understood rules is both expensive and risky.

Shield Standard is automatic and covers the network and transport layers at no extra charge. Shield Advanced is a paid subscription with a response team and cost protection, and it earns its place when an endpoint's downtime is measured in revenue. For a first workload, Standard plus a sensible WAF is the proportionate answer.

Certificates come from ACM, and the validation method is a decision worth making once. DNS validation writes a CNAME into a zone you control and renews without anyone remembering; email validation depends on a person clicking a link at every renewal and breaks when that person leaves. CloudFront requires its certificate in the us-east-1 region regardless of where the workload runs, which surprises almost every first build. TLS 1.2 is the floor, port 80 redirects to 443, and HSTS goes on once the redirect is proven.

CloudWatch gives basic metrics at five-minute resolution, charges for one-minute detail, and bills separately for custom metrics, dashboards and log storage. Log retention is the setting most often left at never-expire. A week for debug output, a month for application logs and a year for audit records is a defensible starting point that keeps the bill proportional to the value.

Alarms should point at symptoms a customer would notice: load balancer 5xx rates, target response time, database connections and free storage, queue depth, and the bytes crossing a NAT gateway. CPU alone is a poor alarm, because it is either a capacity problem or a busy but healthy service, and those need different responses. Every alarm needs a named recipient, otherwise it is a dashboard with extra steps.

Budgets are the cheapest control in the account. A monthly budget with an alert at a fraction of expected spend, a forecast alert, and Cost Anomaly Detection on the services that matter will catch the forgotten instance and the runaway log group. Tags for owner, environment and project turn the invoice into something that can be split; without them the monthly review is an argument about guesses.

AWS charges the card on the account directly. We do not resell capacity or add a margin to usage, so the invoice you see is the one AWS issued, and the setup fee is a separate one-time line agreed before work begins.

Handover is a document set and a walkthrough, not a screen-share where somebody points at a console. You receive the account with root credentials and contacts in your name, a repository that can rebuild the network, and diagrams showing subnets, routes and data flow with the CIDR register beside them.

The access register lists every role, who holds it and what it can do. The logging section names the trail bucket, its retention and its validation setting. The alarm list gives each threshold and the person who receives it. Budget thresholds and the tag scheme are written down alongside the reports they feed.

We also leave a short runbook for the tasks that come up in the first quarter: adding a subnet, issuing a certificate for a new hostname, restoring a database from a snapshot, rotating a credential. One restore is performed during the build rather than described, because a backup nobody has restored is a hope.

What is not included is application work, a migration of existing servers, or round-the-clock operations. Those are separate engagements, and honest scoping now is what stops the first workload landing on a foundation that was never finished.