1.3.2. 💡 First Principle: Shared Responsibility: Customer's Role (Networking Focus)

The customer is responsible for "security in the cloud," securing their network configurations, data flow, and access controls within AWS services, including VPC design and routing.

Scenario: When designing a multi-tier web application, you, as a Network Specialist, are responsible for configuring Security Groups for your web servers and database servers, setting up route tables for proper traffic flow, and encrypting data transmitted over your VPN connections.

In the AWS Shared Responsibility Model, the customer's responsibility is for "security in the cloud." For Network Specialists, this means securing everything they configure and manage within their AWS network environment.

Key Customer Responsibilities ("Security in the Cloud") for Networking:

• VPC Design: Defining VPC CIDR blocks, subnets, and IP addressing schemes.
• Network Access Controls: Configuring Security Groups (instance-level firewall) and Network ACLs (NACLs) (subnet-level firewall) to control traffic to and from resources.
• Routing Configuration: Managing route tables, Internet Gateways, NAT Gateways, VPC Peering connections, and Transit Gateway attachments.
• Hybrid Connectivity Configuration: Configuring Site-to-Site VPNs and Direct Connect Virtual Interfaces.
• DNS Configuration: Managing Amazon Route 53 hosted zones and DNS resolution.
• Network Monitoring & Logging: Configuring VPC Flow Logs and analyzing network traffic.
• DDoS Protection: Implementing AWS WAF and configuring AWS Shield for application-layer and network-layer protection.
• Data Protection (Encryption): Choosing and configuring encryption is the customer's job even when AWS supplies the mechanism (for example, the IPsec settings of a Site-to-Site VPN).
  • In transit: The AWS SDKs and CLI call service endpoints over HTTPS (TLS) by default; a VPC endpoint gives a private path but adds no encryption. For Amazon RDS, require SSL/TLS on the database (e.g. rds.force_ssl for PostgreSQL) and in the client's connection. Transit Gateway and VPC peering carry traffic privately but have no encryption setting of their own, and Direct Connect is unencrypted unless you add MACsec or a VPN; where policy demands encryption, use TLS in the application or IPsec (host-based, or VPN appliances across the TGW). Nitro instances encrypt instance-to-instance traffic automatically only between supported instance types, so it cannot be assumed for every flow.
  • At rest: S3 applies SSE-S3 default encryption to new objects; to require a specific KMS key, set SSE-KMS default encryption and/or a bucket policy that denies s3:PutObject unless s3:x-amz-server-side-encryption is aws:kms. RDS storage encryption is chosen at launch. An unencrypted EBS volume or AMI cannot be encrypted in place — copy the AMI/snapshot with encryption enabled (or turn on EBS encryption by default for new volumes).

⚠️ Common Pitfall: Assuming default configurations are secure enough. Many AWS services have permissive defaults for ease of use, but it's the customer's responsibility to harden them according to their security requirements.

Key Trade-Offs:

• Customer Control vs. AWS Management: The customer has full control over their network configurations, which provides flexibility but also places the burden of secure configuration on them.

Reflection Question: How does failing to configure Security Groups properly or mismanaging route table entries directly demonstrate a failure in your responsibility for "security in the cloud" within the Shared Responsibility Model for networking?