AWS service dependencies
[ROOT] AWS Account & IAM (Identity & Access Management)
║
╠═══► [PARENT] Amazon VPC (Virtual Private Cloud)
║ ║
║ ╚═══► [CHILD] Subnets (Public / Private)
║ ║
║ ╠═══► [CHILD] Security Groups (Firewall Layer)
║ ║ ║
║ ║ ╠═══► [LEAF] EC2 Instances (Requires: IAM Profile + Subnet + SG)
║ ║ ╠═══► [LEAF] RDS Databases (Requires: DB Subnet Group + SG)
║ ║ ╠═══► [LEAF] ElastiCache (Requires: Cache Subnet Group + SG)
║ ║ ╚═══► [LEAF] Application Load Balancer (Requires: 2+ Subnets + SG)
║ ║
║ ╚═══► [CHILD] ECS & EKS Clusters (Containers)
║ ║
║ ╚═══► [LEAF] Fargate Tasks / K8s Nodes (Requires: VPC + IAM + ECR)
║
╠═══► [PARENT] Amazon S3 (Simple Storage Service)
║ ║
║ ╠═══► [CHILD] Amazon CloudFront (CDN) (Requires: S3 Bucket or ALB as Origin)
║ ╠═══► [CHILD] AWS CloudTrail (Auditing) (Requires: S3 for log delivery)
║ ╚═══► [CHILD] Amazon Athena (Analytics) (Requires: S3 Data Source)
║
╚═══► [PARENT] AWS Lambda (Serverless Compute)
║
╠═══► [CHILD] Amazon API Gateway (Requires: Lambda backend to route requests)
╚═══► [CHILD] VPC-Connected Lambda (Requires: VPC + Subnet + SG to touch private RDS)
To set these up correctly, you have to follow a specific logical order because AWS will literally throw an error if you try to create a child resource before its parent container exists.
Here is the exact step-by-step order you must follow, along with the "why."
The Correct Provisioning Order 1. VPC (Virtual Private Cloud) What it is: The foundational boundary line.
Why first: This is your isolated slice of the AWS cloud. Both the Subnet and the Security Group cannot exist without a VPC ID to attach themselves to.
- Subnet What it is: A designated chunk of IP addresses inside your VPC.
Why second: A subnet needs to be carved out of an existing VPC's IP range (CIDR block). You cannot define a subnet in a network that doesn't exist yet.
- Security Group What it is: The virtual firewall for your instance.
Why third: Security Groups are bound to a specific VPC. Additionally, when you write the firewall rules (e.g., "allow traffic from Web-Subnet to DB-Subnet"), you often need the IP ranges from the Subnets you created in Step 2 to write those rules accurately.
- IAM Instance Profile What it is: The container that passes an IAM role to an EC2 instance.
Why it can be done anytime before the EC2 launch: IAM is a global service and completely independent of your network layer. It doesn't care about your VPC or Subnets. However, it must exist before you boot the server if you want the server to have permissions from day one.
- EC2 Instance (The Final Step) Why last: When you finally hit "Launch" on an EC2 instance, the AWS API demands the following inputs: Which Subnet should I drop this in? Which Security Group should protect it? Which IAM Instance Profile should give it permissions? If steps 1–4 aren't done, your EC2 instance has nowhere to live, no firewall to protect it, and no permissions to run.
Summary Flowchart
[ IAM Instance Profile ] (Independent)
│
▼
[ VPC ] ──► [ Subnet ] ──► [ Security Group ]
│ │ │
└────────────┼──────────────────┘
▼
[ EC2 Instance ]
| If you want to use... | You MUST set up this first... | Why? |
|---|---|---|
| EC2 Instance | IAM Instance Profile + VPC + Subnet + Security Group | It requires an identity/permissions, a virtual network location, and a firewall to control traffic. |
| RDS Database | VPC + DB Subnet Group + Security Group | It needs isolated network placement spanning multiple availability zones and firewall rules to restrict database access. |
| AWS Lambda | IAM Execution Role (+ VPC if accessing private resources) | It cannot run without an execution role granting it permission to write logs or access other AWS resources. |
| EKS (Kubernetes) | VPC (Multi-AZ) + IAM Cluster/Node Roles + ECR | Kubernetes requires a robust network, specific IAM roles for the control plane and nodes, and a registry to pull container images. |
| ECS (Fargate / Container) | VPC + Subnets + Security Group + IAM Task/Execution Roles + ECR | Containers require isolated network space, a secure firewall, permissions to pull images/write logs, and a container registry. |
| S3 Bucket | IAM Identity/Permissions (+ Bucket Policy for fine-grained control) | While a global service requiring no network setup, you must define who has permission to read or write data to it. |
| DynamoDB | IAM Permissions (+ VPC Endpoint if keeping traffic off the public internet) | As a fully managed NoSQL database, its primary gatekeeper is IAM identity access management. |
| API Gateway | Backend Target (Lambda, HTTP, or AWS Service) + IAM Roles | An API gateway is just a front door; it must have a configured backend to route traffic to, and permission to invoke it. |
| Application Load Balancer (ALB) | VPC + At least 2 Subnets (Different AZs) + Security Group + Target Group | An ALB requires a network path across multiple availability zones, a firewall, and a registered group of backend targets to route traffic to. |
| CloudFront (CDN) | Origin Source (S3 Bucket or ALB) + Origin Access Control (OAC) (+ ACM Certificate for HTTPS) | A content delivery network requires a data origin to fetch content from, secure permissions to read from it, and an SSL certificate for custom domains. |
| Route 53 (DNS) | Public/Private Hosted Zone + Target Resource (ALB, CloudFront, or S3) | DNS routing requires a registered zone configuration to map domain names to specific backend AWS resource endpoints. |
| ElastiCache (Redis/Memcached) | VPC + Cache Subnet Group + Security Group | As an in-memory caching layer, it must live securely inside your private network near your compute resources. |
| Redshift (Data Warehouse) | VPC + Cluster Subnet Group + Security Group + IAM Role | Heavy data warehousing requires isolated network subnets, a firewall, and an IAM role to pull or dump bulk data from S3. |
| SQS / SNS (Queues & Notifications) | IAM Policies / Access Policies | These decoupled messaging services rely strictly on permissions to dictate who can publish, subscribe, send, or receive messages. |
| Cognito (Auth & Identity) | IAM Roles (Authenticated & Unauthenticated) | To hand out temporary AWS credentials to mobile or web users, Cognito needs pre-configured IAM roles to attach to those users. |
[ROOT] AWS Account & IAM (Identity & Access Management)
║
╠═══► [PARENT] Amazon VPC (Virtual Private Cloud)
║ ║
║ ╚═══► [CHILD] Subnets (Public / Private)
║ ║
║ ╠═══► [CHILD] Security Groups (Firewall Layer)
║ ║ ║
║ ║ ╠═══► [LEAF] EC2 Instances (Requires: IAM Profile + Subnet + SG)
║ ║ ╠═══► [LEAF] RDS Databases (Requires: DB Subnet Group + SG)
║ ║ ╠═══► [LEAF] ElastiCache (Requires: Cache Subnet Group + SG)
║ ║ ╚═══► [LEAF] Application Load Balancer (Requires: 2+ Subnets + SG)
║ ║
║ ╚═══► [CHILD] ECS & EKS Clusters (Containers)
║ ║
║ ╚═══► [LEAF] Fargate Tasks / K8s Nodes (Requires: VPC + IAM + ECR)
║
╠═══► [PARENT] Amazon S3 (Simple Storage Service)
║ ║
║ ╠═══► [CHILD] Amazon CloudFront (CDN) (Requires: S3 Bucket or ALB as Origin)
║ ╠═══► [CHILD] AWS CloudTrail (Auditing) (Requires: S3 for log delivery)
║ ╚═══► [CHILD] Amazon Athena (Analytics) (Requires: S3 Data Source)
║
╚═══► [PARENT] AWS Lambda (Serverless Compute)
║
╠═══► [CHILD] Amazon API Gateway (Requires: Lambda backend to route requests)
╚═══► [CHILD] VPC-Connected Lambda (Requires: VPC + Subnet + SG to touch private RDS)
- Labeled Number Structure (Parent-Child Hierarchy) 1.0 THE ROOT LAYER: Security, Identity & Governance Every single resource in AWS requires this layer to exist first. It has no internal AWS dependencies.
1.1 AWS IAM (Identity and Access Management)
Type: Root Parent.
Children: Every service below. Nothing can be provisioned or granted access without IAM roles, policies, or users.
2.0 THE NETWORK LAYER: Boundary Infrastructure You cannot launch server-based, database, or containerized resources without this network wrapper.
2.1 Amazon VPC
Parent: 1.1 IAM (for creation permissions).
Children: 2.2 Subnets, 2.3 Security Groups.
2.2 Subnets (Public & Private)
Parent: 2.1 Amazon VPC (Must be assigned an IP block inside the VPC).
Children: 2.4 EC2, 2.5 RDS, 2.6 Application Load Balancers (ALB), 2.7 ECS/EKS.
2.3 Security Groups (Stateful Firewalls)
Parent: 2.1 Amazon VPC (Must be explicitly attached to a specific VPC).
Children: Direct dependencies for 2.4 EC2, 2.5 RDS, 2.6 ALB.
3.0 THE COMPUTE & DATA LAYER: Core Workloads These are the transactional resources that do the actual work, depending entirely on Layers 1.0 and 2.0.
3.1 Amazon EC2 (Virtual Servers)
Parents: 1.1 IAM (Instance Profile), 2.2 Subnet (Location), 2.3 Security Group (Firewall).
Children: None (Self-contained execution unit).
3.2 Amazon RDS (Managed Databases)
Parents: 2.2 Subnets (Requires a "DB Subnet Group" across 2+ Availability Zones), 2.3 Security Group.
Children: 3.1 EC2 or 4.1 Lambda (which connect to it as clients).
3.3 Application Load Balancer (ALB)
Parents: 2.2 Subnets (Requires at least 2 public/private subnets), 2.3 Security Group.
Children: Routes traffic downstream to 3.1 EC2 or 3.4 Containers.
3.4 ECS & EKS (Container Management)
Parents: 1.1 IAM (Task/Execution Roles), 2.2 Subnets, 2.3 Security Groups, AWS ECR (Elastic Container Registry) (to pull the Docker images).
4.0 THE SERVERLESS & GLOBAL EDGE LAYER: Event-Driven & Caching These services abstract the network layer away unless they need to interact with Layer 3.0 services.
4.1 AWS Lambda (Functions)
Parent: 1.1 IAM (Mandatory Execution Role).
Note: It only becomes a child of 2.1 VPC if it explicitly needs to talk to a private resource like 3.2 RDS.
4.2 Amazon API Gateway
Parent: 4.1 AWS Lambda or 3.3 ALB. (An API Gateway cannot exist in a vacuum; it requires a backend target to forward API requests to).
4.3 Amazon CloudFront (CDN)
Parent: Amazon S3 or 3.3 ALB. (CloudFront caches static files or routes dynamic traffic; it requires an "Origin" resource to pull data from).
[AWS::IAM::Role] ────────────────┐
│ (Assumed by) │
[AWS::IAM::InstanceProfile] │ (Provides access to)
│ ▼
│ [AWS::KMS::Key] (For data encryption)
│ │
│ ▼
│ [AWS::EC2::Volume] (EBS Boot Disk)
│ │
│ ▼
[AWS::EC2::VPC] ──────────► [AWS::EC2::Subnet] ──► [AWS::EC2::Instance]
│ ▲ ▲
├──► [AWS::EC2::NetworkAcl] │
│ │
├──► [AWS::EC2::InternetGateway] │
│ │ │
│ ▼ │
├──► [AWS::EC2::VPCGatewayAttachment] │
│ │ │
│ ▼ │
└──► [AWS::EC2::RouteTable] │
│ │
├─► [AWS::EC2::Route] (0.0.0.0/0 -> IGW) │
│ │
└─► [AWS::EC2::SubnetRouteTableAssociation]
│
[AWS::EC2::SecurityGroup] ─────────────────────────────────┘
│
└──► [AWS::EC2::SecurityGroupIngress] (Port 8443 / 443 rules)
[ User Browser ]
│
▼
1. [ Route 53 ] ──────────► (Fails? The domain name won't resolve to an IP)
│
▼
2. [ CloudFront CDN ] ────► (Fails? Dynamic content can't be cached or routed)
│
▼
3. [ AWS WAF ] ───────────► (Fails? Traffic is blocked before reaching the compute layer)
│
▼
4. [ ALB Load Balancer ] ─► (Fails? Traffic cannot be distributed to servers)
│
▼
5. [ EC2 / Containers ] ──► (Fails? The actual business logic application crashes)
│
▼
6. [ RDS Database ] ──────► (Fails? The application can't fetch the user's data)
│
▼
7. [ Amazon S3 ] ─────────► (Fails? The actual image file cannot be downloaded)