- Three subnet types: Private, Public and VPN
- Single Region, multi AZs
- Security Groups:
- Resources level traffic firewall (EC2 instance, ELB, etc..)
- Ingress and Egress
- Stateful
- Access Control Lists:
- Source and Protocol filtering
- Subnet level trafic firewall
- Stateless
| NAT Instances | NAT Gateways |
|---|---|
| Use script to manage fail over between instances | Highly available, are implement with redundancy in each AZs |
| Depends on the bandwidth of intance type | Is a service |
| Manage by you | Managed by AWS |
| A generic AMI that's configured to perform NAT | Software is optimized for handling NAT traffic |
| Manual port fordwarding | Port fordwarding NOT supported |
| Use a bastion server | Bastion server not supported |
| View CloudWatch alarms | Traffic metrics not supported |
- Single region Inter-VPC routing
- Connection between same or different AWS account
- DNS supported
| VPN | Gateways |
|---|---|
| Hardware-based VPN (w/ port redundancy) | Internet Gateway (IGW) |
| Direct Connect | Virtual Private Gateway |
| VPN CloudHub | Customer Gateway |
| Software VPN | Software is optimized for handling NAT traffic |
- Predictable bandwidth
- Predictable performance/consistent network experience
- Support for VLAN Trunking (802.1Q)
- Can be partitioned into multiple Virtual Interfaces
- Direct connection to VPC for Branch offices
- Subnets do not span over AZs
- Update the inbound or outbound rules for your VPC Security Groups to reference Security Groups in the peered VPC
- VPC Peering: Can't overlap network addresses
- Direct Connect:
- Bandwidth of 1 Gbps or 10 Gbps
- Performance and bandwidth depends on distance of AWS Region / Edge Router
-
The first four IP addresses and the last IP address in each subnet CIDR block are not available for you to use, and cannot be assigned to an instance. For example, in a subnet with CIDR block 10.0.0.0/24, the following five IP addresses are reserved:
-
10.0.0.0: Network address.
-
10.0.0.1: Reserved by AWS for the VPC router.
-
10.0.0.2: Reserved by AWS. The IP address of the DNS server is always the base of the VPC network range plus two; however, we also reserve the base of each subnet range plus two. For VPCs with multiple CIDR blocks, the IP address of the DNS server is located in the primary CIDR. For more information, see Amazon DNS Server.
-
10.0.0.3: Reserved by AWS for future use.
-
10.0.0.255: Network broadcast address. We do not support broadcast in a VPC, therefore we reserve this address.
-
-
CIDR : 16-28
-
VPC Peering: 50 VPC Peers per VPC, up to 125 by request
- On-demand: paid for use
- Reserved Intances:
- Standard
- Scheduled
- Spot
- Dedicated:
- Host
- Instance
- Low cost and flexibility with no up front cost
- Ideal for autoscaling groups and unpredictable workloads
- Dev / Test
- Steady state and predictable usage
- Aplications that need reserved capacity
- Flexible start and end times
- Grid computing and HPC
- Very low hourly compute cost
- Predictable performance
- Complete Isolation
- Most expensive
- Bath processing of compute intensive workloads
- Requires high performance CPU, network and storage
- Jumbo frames are typically required: Transport large amount of data quicker than over a traditional network (a lot of I/O - NFS is suitable in this case)
- Jumbo frame: up to 9000 bytes of data (vs standard frame only 1500 bytes)
- Supported on AWS through enhanced networking (single rout I/O virtualization (SR-IOV))
- A logical grouping of instances in a single availability zone
- Keep them as close as possible to each other in order to allow for low latency and high performance between these instances
- Can span peered VPCs (but not at full performance)
- Placement Groups:
- Can't span multiple availability zones
- Reserved instances are supported on an instance level but you cannot explicity reserved CAPACITY for a placement group
- You can't merge them
- The name must be unique (like S3 unique name convention)
- Cannot be merged
- Region wide load balancer (not an VM / Appliance)
- Can be used internally or externally
- Layer 4 or Layer 7
- SSL termination and processing
- Cookie-based sticky sessions
- Integrate with Auto Scaling
- ELB EC2 health checks / CloudWatch
- Integrate with Route 53
- Supported ports:
- 25 (SMTP)
- 80/443 (HTTP/HTTPS)
- 1024-65535
- Support Domain Zone Apex
- Support IPv4 and IPv6
- Integrate with CloudTrail for log security analisis
- Multiple SSL certificates required multiples ELBs
- Wildcard are supported
- Associate with DNS
- Layer 7 Only
- Content-based routing
- Region Wide load balancer
- Support for microservices and containers
- Integrate with ECS
- Better performance for realtime streaming
- Reduced hourly cost
- Deletion protection
- Better health checks and CloudWatch metrics
- Listeners:
- Define the port and protocol
- Each ALB needs at least on listener
- Up to 10 listeners
- Routing rules are defined on listeners
- Target groups:
- Logical grouping of targets
- Made up of EC2 instances or containers
- Can exist independently from the ALB
- Region-based but can be associated with an auto scaling group
- Rules:
- Fordwards incoming request to specific target groups
- One or more rules
- Improved Health Check:
- Custom response codes: 200-399
- Detailed health check failures displayed in the API and management console
- Detailed access to log information
- Saved to an S3 bucket every 5 or 60 minutes
- About 10% cheaper
- Classic LB:
- Doesn't support Elastic IP
- Can't reach through IP address, only DNS name
- AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources. You use IAM to control who is authenticated (signed in) and authorized (has permissions) to use resources.
- Shared access to your AWS account
- Granular permissions
- Secure access to AWS resources for applications that run on Amazon EC2
- Multi-factor authentication (MFA)
- Identity federation
- PCI DSS Compliance
- Integrated with many AWS services
- Eventually Consistent
- Free to use
- AWS Management Console
- AWS Command Line Tools
- AWS SDKs
- IAM HTTPS API
The IAM infrastructure includes the following elements:
- Principal: Make a request for an action or operation on an AWS resource. Users, roles, federated users, and applications are all AWS principals.
- Request: The principal sends a request to AWS when tries to use the AWS Management Console, the AWS API, or the AWS CLI,
- Authentication: As a principal, you must be authenticated (signed in to AWS) to send a request to AWS.
- Authorization: During authorization, AWS uses values from the request context to check for policies that apply to the request. It then uses the policies to determine whether to allow or deny the request.
- Actions or Operations: Things that you can do to a resource, such as viewing, creating, editing, and deleting that resource.
- Resources: A resource is an object that exists within a service.
When you create an AWS account (with password and email), you create an AWS account root user identity. This combination of your email address and password is also called your root user credentials.
You can create individual IAM users within your account that correspond to users in your organization. IAM users are not separate accounts.
If the users in your organization already have a way to be authenticated, such as by signing in to your corporate network, you don't have to create separate IAM users for them. Instead, you can federate those user identities into AWS. Federation is particularly useful in these cases:
- Your users already have identities in a corporate directory.
- Your users already have Internet identities.
Access management define what a user or other entity is allowed to do in an account. This process is often referred to as authorization.
If you manage a single account in AWS, then you define the permissions within that account using policies.
ou give permissions to a user by creating an identity-based policy, which is a policy that is attached to the user
You can organize IAM users into IAM groups and attach a policy to a group.
Federated users don't have permanent identities in your AWS account the way that IAM users do. To assign permissions to federated users, you can create an entity referred to as a role and define permissions for the role.
Identity-based policies are permissions policies that you attach to a principal (or identity), such as an IAM user, group, or role.
-
Managed policies – Standalone identity-based policies that you can attach to multiple users, groups, and roles in your AWS account. Two types:
-
AWS managed policies – Managed policies that are created and managed by AWS.
-
Customer managed policies – Managed policies that you create and manage in your AWS account.
-
-
Inline policies – Policies that you create and manage and that are embedded directly into a single user, group, or role.
Resource-based policies control what actions a specified principal can perform on that resource and under what conditions. Resource-based policies are inline policies, and there are no managed resource-based policies.
Trust policies are resource-based policies that are attached to a role. They define which principals can assume the role.
Some AWS products have other ways to secure their resources
- Amazon EC2: You log into an instance with a key pair (for Linux instances) or using a user name and password (for Microsoft Windows instances).
- Amazon RDS: You log into the database engine with a user name and password that are tied to that database.
- Amazon EC2 and Amazon RDS: You use security groups to control traffic to an instance or database.
- Amazon WorkSpaces: Users sign in to a desktop with a user name and password.
- Amazon WorkDocs: Users get access to shared documents by signing in with a user name and password.
- Lock Away Your AWS Account Root User Access Keys
- Create Individual IAM Users
- Use Groups to Assign Permissions to IAM Users
- Use AWS Defined Policies to Assign Permissions Whenever Possible
- Grant Least Privilege
- Use Access Levels to Review IAM Permissions
- Configure a Strong Password Policy for Your Users
- Enable MFA for Privileged Users
- Use Roles for Applications That Run on Amazon EC2 Instances
- Use Roles to Delegate Permissions
- Do Not Share Access Keys
- Rotate Credentials Regularly
- Remove Unnecessary Credentials
- Use Policy Conditions for Extra Security: restrict IP address, enable MFA
- Monitor Activity in Your AWS Account
- The AWS Account Root User
- IAM Users
- IAM Groups
- IAM Roles
- Temporary Credentials
- If a request to change some data is successful, the change is committed and safely stored. However, the change must be replicated across IAM, which can take some time. Such changes include creating or updating users, groups, roles, or policies. We recommend that you do not include such IAM changes in the critical, high-availability code paths of your application.
- Policies and Users: Actions or resources that are not explicitly allowed are denied by default.
- You cannot attach a resource-based policy to an IAM identity.
- Do not use your AWS account root user access key
- IAM Group are not truly an identity because it cannot be identified as a Principal in a resource-based or trust policy.
- IAM Roles does not have any credentials (password or access keys) associated with it.
- Up to two access keys per IAM user